Re: RFI: Extending the TOAST Pointer - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: RFI: Extending the TOAST Pointer
Date
Msg-id CAJ7c6TMko_Y_7Eh262sqj=uRjiY+f_HcGMCKwyjObXX8H4hy3g@mail.gmail.com
Whole thread Raw
In response to Re: RFI: Extending the TOAST Pointer  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Responses Re: RFI: Extending the TOAST Pointer
List 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 by date:

Previous
From: Ian Lawrence Barwick
Date:
Subject: Re: PG 16 draft release notes ready
Next
From: Nathan Bossart
Date:
Subject: Re: createuser --memeber and PG 16