Gokulakannan Somasundaram wrote:
> Say, with a normal index, you need to goto the table for checking the
> snapshot. So you would be loading both the index pages + table pages, in
> order to satisfy a certain operations. Whereas in thick index you occupy 16
> bytes per tuple more in order to avoid going to the table. So memory
> management is again better. But i can run the load test, if that's
> required.
Yes, performance testing is required for any performance-related patch.
Remember that you're competing against DSM. We're going to want some
kind of a DSM anyway because it allows skipping unmodified parts of the
heap in vacuum.
> Even when all the tuples are in memory, index only scans are
> almost 40-60% faster than the index scans with thin indexes.
Have you actually benchmarked that? What kind of query was that? I don't
believe for a second that fetching the heap tuple when the page is in
memory accounts for 40-60% of the overhead of regular index scans.
> What do you thick about not maintaining pins in case of thick indexes?
Seems irrelevant. Keeping a page pinned is cheap.
BTW, another issue you'll have to tackle, that a DSM-based patch will
have to solve as well, is how to return tuples from an index. In b-tree,
we scan pages page at a time, keeping a list of all tids that match the
scanquals in BTScanOpaque. If we need to return not only the tids of the
matching tuples, but the tuples as well, where do we store them? You
could make a palloc'd copy of them all, but that seems quite expensive.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com