Re: pgsql: Add deduplication to nbtree.

Поиск
Список
Период
Сортировка
Искать
От
Peter Geoghegan
Тема
Re: pgsql: Add deduplication to nbtree.
Дата
Msg-id
CAH2-WzmAufHiOku6AGiFD=81VQs5nYJ1L2YkhW1t+BH4CMsgRw@mail.gmail.com
Ответ на
Список
Дерево обсуждения
pgsql: Add deduplication to nbtree. Peter Geoghegan <pg@bowt.ie>
Re: pgsql: Add deduplication to nbtree. Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Re: pgsql: Add deduplication to nbtree. Peter Geoghegan <pg@bowt.ie>
Re: pgsql: Add deduplication to nbtree. Peter Geoghegan <pg@bowt.ie>
Re: pgsql: Add deduplication to nbtree. Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql: Add deduplication to nbtree. Peter Geoghegan <pg@bowt.ie>
Re: pgsql: Add deduplication to nbtree. Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql: Add deduplication to nbtree. Peter Geoghegan <pg@bowt.ie>
Re: pgsql: Add deduplication to nbtree. Peter Geoghegan <pg@bowt.ie>
Re: pgsql: Add deduplication to nbtree. Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql: Add deduplication to nbtree. Peter Geoghegan <pg@bowt.ie>
Re: pgsql: Add deduplication to nbtree. Peter Geoghegan <pg@bowt.ie>
Re: pgsql: Add deduplication to nbtree. Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql: Add deduplication to nbtree. Peter Geoghegan <pg@bowt.ie>
Re: pgsql: Add deduplication to nbtree. Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql: Add deduplication to nbtree. Peter Geoghegan <pg@bowt.ie>
Re: pgsql: Add deduplication to nbtree. Andres Freund <andres@anarazel.de>
Re: pgsql: Add deduplication to nbtree. Peter Geoghegan <pg@bowt.ie>
Re: pgsql: Add deduplication to nbtree. Andres Freund <andres@anarazel.de>
Re: pgsql: Add deduplication to nbtree. Laurenz Albe <laurenz.albe@cybertec.at>
Re: pgsql: Add deduplication to nbtree. Peter Geoghegan <pg@bowt.ie>
Re: pgsql: Add deduplication to nbtree. Peter Geoghegan <pg@bowt.ie>
On Sun, Mar 1, 2020 at 11:29 AM Tom Lane  wrote:
> Hm.  That would probably be enough to shut up Coverity, but I'm unsure
> whether it'd really be an improvement from the legibility and safety
> viewpoints.

I noticed that _bt_update_posting() behaves as if the origtuple might
not be a posting list tuple at the point that keysize is calculated,
despite generally depending on it being a posting list tuple (which it
asserts by way of its "_bt_posting_valid(origtuple)" assertion). The
final tuple might not be a posting list, but the original one must be
(if it isn't, then nbtree VACUUM should be deleting it outright in the
traditional way, rather than updating it). I should fix that, either
way.

> Do you want to try coding it that way and see what it
> comes out like?

Sure.

-- 
Peter Geoghegan


В списке pgsql-committers по дате отправления
От: Tom Lane
Дата:
От: Peter Geoghegan
Дата:
FAQ