Re: Indexed views? - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Indexed views?
Date
Msg-id Pine.OSF.4.61.0409121622490.357432@kosh.hut.fi
Whole thread Raw
In response to Re: Indexed views?  (Tiago Wright <tiagowright@gmail.com>)
List pgsql-hackers
On Sat, 11 Sep 2004, Tiago Wright wrote:

> IMHO, it is worth duplicating the mvcc data to all index entries. To
> summarize what I understand from this discussion, with the current
> method:
>
> a1 - Index seeks must return invisible tuples because mvcc data is not
> found in the index. These tuples are eliminated once the data is read
> from the actual data pages.
>
> a2 - Covered queries are not possible since the data page must be
> visited to determine visibility

a4 - Indexes must be fully vacuumed before vacuuming the corresponding 
heap entries

> If mvcc data is replicated to the index entries:
>
> b1 - Index seeks will never return invisible tuples, possibly
> eliminating some page reads
>
> b2 - Covered queries are possible
>
> b3 - Inserts are not affected performancewise. Deletes must now visit
> every index entry, which is a larger cost. Updates must visit every
> index entry too. It may be possible to reduce the cost of update if
> the indexed data is not affected, since the new index entry will
> likely end up in the same page as the index entry that must be
> deleted, so no extra page reads would be necessary in this scenario.

b4 - Heap and index pages can be vacuumed independently.

> Since the great majority of performance issues are related to select
> queries, the benefit of eliminating invisible tuple page fetches and
> supporting covered queries probably outweight the extra cost of
> updating index entries. And once covered queries are supported, it
> would be possible to build indexed views or multi-table indexes that
> can address some of the most performance demanding queries out there.
>
> I am wondering whether it would be possible to measure the costs of a1
> and a2 above and compare with the probable costs for b3. It seems to
> me that applications for which b3 are most expensive are also those
> for which a1 would be most expensive, and since selects are much more
> common than updates, could one offset the other in the long run? Can
> anyone shed some light on these?

If it seems that there are some cases where it's better to have the 
visibility information in the index and some cases where not, I think we 
could support both kinds of indexes and let the DBA choose.

- Heikki



pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: SELECT FOR UPDATE NOWAIT and PostgreSQL 8.0
Next
From: Tom Lane
Date:
Subject: Re: beta1 & beta2 & Windows & heavy load