Re: Indexed views?

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.

In response to

Responses

Browse pgsql-hackers by date

  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