Re: Killing dead index tuples before they get vacuumed
От | Jan Wieck |
---|---|
Тема | Re: Killing dead index tuples before they get vacuumed |
Дата | |
Msg-id | 200205221535.g4MFZgv02701@saturn.janwieck.net обсуждение исходный текст |
Ответ на | Re: Killing dead index tuples before they get vacuumed (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Killing dead index tuples before they get vacuumed
|
Список | pgsql-hackers |
Tom Lane wrote: > Hannu Krosing <hannu@tm.ee> writes: > > On Wed, 2002-05-22 at 12:28, Zeugswetter Andreas SB SD wrote: > >> While I agree that it might be handy to save this bit for future use, > >> I do not see any value in increasing the max key length from 8k, > > > I'm not sure if it applies here, but key length for GIST indexes may > > benefit from 2x increase (14bits = 16k). IIRC limited key length is one > > reason for intarray indexes being 'lossy'. > > Since there seems to be some dissension about that, I'll leave the > t_info bit unused for now, instead of absorbing it into the length > field. > > Since 13 bits is sufficient for 8K, people would not see any benefit > anyway unless they use a nonstandard BLCKSZ. So I'm not that concerned > about raising it --- just wanted to throw out the idea and see if people > liked it. Also, in btree haven't we had some problems with index page splits when using entries large enought so that not at least 3 of them fit on a page? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-hackers по дате отправления: