Re: PG_PAGE_LAYOUT_VERSION 5 - time for change
| От | Tom Lane |
|---|---|
| Тема | Re: PG_PAGE_LAYOUT_VERSION 5 - time for change |
| Дата | |
| Msg-id | 9097.1225410883@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: PG_PAGE_LAYOUT_VERSION 5 - time for change (Gregory Stark <stark@enterprisedb.com>) |
| Ответы |
Re: PG_PAGE_LAYOUT_VERSION 5 - time for change
|
| Список | pgsql-hackers |
Gregory Stark <stark@enterprisedb.com> writes:
> Tom Lane <tgl@sss.pgh.pa.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
cost?
regards, tom lane
В списке pgsql-hackers по дате отправления: