Re: RFI: Extending the TOAST Pointer

Поиск
Список
Период
Сортировка
От Aleksander Alekseev
Тема Re: RFI: Extending the TOAST Pointer
Дата
Msg-id CAJ7c6TMko_Y_7Eh262sqj=uRjiY+f_HcGMCKwyjObXX8H4hy3g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: RFI: Extending the TOAST Pointer  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Ответы Re: RFI: Extending the TOAST Pointer  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Список pgsql-hackers
Hi,

> We'd need to stop using the va_tag as length indicator, but I don't
> think it's currently assumed to be a length indicator anyway (see
> VARSIZE_EXTERNAL(ptr)). By not using the varatt_external struct
> currently in use, we could be able to get down to <18B toast pointers
> as well, though I'd consider that unlikely.

Agree.

Another thing we have to decide is what to do exactly in the scope of
this thread.

I imagine it as a refactoring that will find all the places that deal
with current TOAST pointer and changes them to something like:

```
switch(va_tag) {
  case DEFAULT_VA_TAG( equals 18 ):
    default_toast_process_case_abc(...);
  default:
    elog(ERROR, "Unknown TOAST tag")
}
```

So that next time somebody is going to need another type of TOAST
pointer this person will have only to add a corresponding tag and
handlers. (Something like "virtual methods" will produce a cleaner
code but will also break branch prediction, so I don't think we should
use those.)

I don't think we need an example of adding a new TOAST tag in scope of
this work since the default one is going to end up being such an
example.

Does it make sense?

-- 
Best regards,
Aleksander Alekseev



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ian Lawrence Barwick
Дата:
Сообщение: Re: PG 16 draft release notes ready
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: createuser --memeber and PG 16