Re: PG_PAGE_LAYOUT_VERSION 5 - time for change

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

>> 2) Add page type (e.g. btree) and subtype (e.g. metapage) flag into page header.
>> I think It will be useful when we will use share buffer for clog.
>
> I think this is a pretty bad idea, because it'll eat space on every page
> for data that is only useful to indexes. I don't believe that clog will
> find it interesting either. To share buffers with clog will require
> a change in buffer lookup tags, not buffer contents.

Another example application which came to mind, if we ever wanted to do
something like retail vacuum, pruning, or hint bit setting from bgwriter it
would have to know how to tell heap pages apart from index pages. I'm not sure
whether that would have to be on the page or if it could be in the buffertag
as well?

If we do decide we want to do this it wouldn't have to be very much space. 16
page types with 16 subtypes each would be plenty which would fit on a single
byte.

>> 3) TOAST modification
>> a) TOAST table per attribute
>> b) replace chunk id with offset+variable chunk size
>> c) add column identification into first chunk
>
> I don't like 3a any more than Greg does. 3b sounds good until you
> reflect that a genuinely variable chunk size would preclude random
> access to sub-ranges of a toast value.

Hm, Heikki had me convinced it wouldn't but now that I try to explain it I
can't get it to work. I think the idea is you start a scan at the desired
offset and scan until you reach a chunk which overruns the end of the desired
piece. However you really need to start scanning at the last chunk *prior* to
the desired offset.

I think you can actually do this with btrees but I don't know if our apis
support it. If you scan to find the first chunk > the desired offset and then
scan backwards one tuple you should be looking at the chunk in which the
desired offset lies.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!