Re: Killing dead index tuples before they get vacuumed
От | Tom Lane |
---|---|
Тема | Re: Killing dead index tuples before they get vacuumed |
Дата | |
Msg-id | 23642.1022075222@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Killing dead index tuples before they get vacuumed (Hannu Krosing <hannu@tm.ee>) |
Ответы |
Re: Killing dead index tuples before they get vacuumed
|
Список | pgsql-hackers |
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. In the long run it'd be possible to not store length in IndexTupleData at all, but rely on the length from the item header, same as we do for heap tuples. So if we ever need more bits in IndexTupleData, there's a way out. regards, tom lane
В списке pgsql-hackers по дате отправления: