Re: Performance penalty of visibility info in indexes?
От | Martijn van Oosterhout |
---|---|
Тема | Re: Performance penalty of visibility info in indexes? |
Дата | |
Msg-id | 20070205152033.GB4811@svana.org обсуждение исходный текст |
Ответ на | Performance penalty of visibility info in indexes? (Jim Nasby <decibel@decibel.org>) |
Список | pgsql-hackers |
On Thu, Feb 01, 2007 at 11:57:41PM -0600, Jim Nasby wrote: > Has anyone actually measured the performance overhead of storing > visibility info in indexes? I know the space overhead sounds > daunting, but even if it doubled the size of the index in many cases > that'd still be a huge win over having to scan the heap as well as > the index (esp. for things like count(*)). There would also be > overhead from having to update the old index tuple, but for the case > of updates you're likely to need that page for the new index tuple > anyway. I thought the main problem was locking. If you change the visibility of an existing row, you have to update the index in a way that won't kill concurrant scans, either by returning the row twice, or skipping it. I think it hinges on what exactly falls under "visibility info". Maybe with the page-at-a-time index scans, the problem is easier now. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
В списке pgsql-hackers по дате отправления: