Skip site navigation (1) Skip section navigation (2)

Re: PG_PAGE_LAYOUT_VERSION 5 - time for change

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PG_PAGE_LAYOUT_VERSION 5 - time for change
Date: 2008-10-30 23:54:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> ... 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.

Yeah, that was my conclusion too.

> 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.

Well, that might work but it would typically cost you an extra fetch.
Do we really have a use case for variable chunk size that is worth the

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Dann CorbitDate: 2008-10-31 00:17:23
Subject: Strange query behavior where clause produces odd behavior on '>' query
Previous:From: Gregory StarkDate: 2008-10-30 23:33:27
Subject: Re: PG_PAGE_LAYOUT_VERSION 5 - time for change

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group