From: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
---|---|
To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Nikita Malakhov <hukutoc(at)gmail(dot)com> |
Subject: | Re: RFI: Extending the TOAST Pointer |
Date: | 2023-05-21 13:39:20 |
Message-ID: | CAJ7c6TMko_Y_7Eh262sqj=uRjiY+f_HcGMCKwyjObXX8H4hy3g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2023-05-21 14:44:49 | Re: createuser --memeber and PG 16 |
Previous Message | Ian Lawrence Barwick | 2023-05-21 12:30:01 | Re: PG 16 draft release notes ready |