Skip site navigation (1) Skip section navigation (2)

Re: Serious performance problem

From: Denis Perchine <dyp(at)perchine(dot)com>
To: Alex Pilosov <alex(at)pilosoft(dot)com>, Antonio Fiol Bonn?n <fiol(at)w3ping(dot)com>
Cc: Brent Verner <brent(at)rcfile(dot)org>, "Tille, Andreas" <TilleA(at)rki(dot)de>, "Claus, Hermann" <ClausH(at)rki(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Serious performance problem
Date: 2001-10-31 18:26:10
Message-ID: 200110311907.f9VJ7lP85231@postgresql.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tuesday 30 October 2001 21:24, Alex Pilosov wrote:
> > > | The consequence for my problem is now:  If it is technically possible
> > > | to implement index scans without table lookups please implement it. 
> > > | If
>
> The feature you are looking for is called 'index coverage'. Unfortunately,
> it is not easy to implement with Postgresql, and it is one of few
> outstanding 'nasties'. The reason you can't do it is follows: Postgres
> uses MVCC, and stores 'when' the tuple is alive inside the tuple. So, even
> if index contains all the information you need, you still need to access
> main table to check if the tuple is valid.
>
> Possible workaround: store tuple validity in index, that way, a lot more
> space is wasted (16 more bytes/tuple/index), and you will need to update
> all indices when the base table is updated, even if indexed information
> have not changed.

What is the problem to implement this index as a special index type for 
people who need this? Just add a flag keyword to index creation clause.

Actually I would like to hear Tom's opinion on this issue. This issue is of 
my interest too.

Also I saw sometime ago in hackers that there is a patch implementing this...
Or I am wrong here?

--
Denis


In response to

pgsql-hackers by date

Next:From: Philip WarnerDate: 2001-11-01 04:16:06
Subject: Another planner/optimizer question...
Previous:From: Thomas LockhartDate: 2001-10-31 14:47:51
Subject: Re: timetz regression test is showing several DST-related failures

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group