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 по дате отправления: