From: | Mischa Sandberg <ischamay(dot)andbergsay(at)activestateway(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Indexed views? |
Date: | 2004-09-08 15:53:41 |
Message-ID: | 9WF%c.159843$X12.131146@edtnps84 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark wrote:
> Doug McNaught <doug(at)mcnaught(dot)org> writes:
>
>
>>Short answer: MVCC tuple visibility status isn't (and can't be) stored
>>in the index.
>
>
> Well the "can't" part is false or at least unproven. From prior discussion the
> only thing that would be technically challenging would be avoiding deadlocks.
Rather than yank the MVCC visibility around, how about a (relatively
small) change to the query plan ...
I take it that it is a very reasonable assumption that only a small
proportion of index records are actually invalid (else Yurk why use the
index?). In that case, how about tacking the heap table row ptr onto
result tuples, and letting them percolate up through the tree?
Since you're using an index at all, the planner must be expecting a
restricted set of rows to make it up through to the root. If there is
any filter criteria against the values from the index rows, you won't
even have to check rows for tuple visibility, that don't pass that filter.
As soon as you rise to a point where (index) rows will either be
multiplied (a join) or combined (a group-by/distinct), you can validate
them against the heap file in relatively large batches, with a hash
caching of which ones have been checked for visibility.
Just a thought.
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2004-09-08 19:32:38 | Re: Contrib modules on Win32 |
Previous Message | Tom Lane | 2004-09-08 15:15:49 | Re: Making AFTER triggers act properly in PL functions |