Re: Serious performance problem

From: Horst Herb <hherb(at)malleenet(dot)net(dot)au>
To: "Tille, Andreas" <TilleA(at)rki(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Serious performance problem
Date: 2001-10-31 03:37:29
Message-ID: 20011031033311.4792.qmail@gnumed.dhs.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wednesday 31 October 2001 03:13, you wrote:
> On Tue, 30 Oct 2001, Alex Pilosov wrote:

> As I said all this wouln´t be a problem for my application. I just
> run a sequential insert of data each night. Then the database is read
> only.
>
> Does anybody see chances that 'index coverage' would be implemented into
> 7.2. This would be a cruxial feature for my application. If it will

Andreas,

I have the feeling that your problem is solved best by taking a different
approach.
As A. Pilosovs posting pointed out, index coverage is a problem intrinsic to
the MVCC implementation (IMHO a small price to pay for a priceless feature).
I can't see why much effort should go into a brute force method to implement
index coverage, if your problem can be solved more elegant in a different way.

With the example you posted, it is essentially only simple statistics you
want to run on tables where the *majority* of records would qualify in your
query.
Why not create an extra "statistics" table which is updated automatically
through triggers in your original table? That way, you will always get
up-to-date INSTANT query results no matter how huge your original table is.

And, don't forget that the only way MS SQL can achieve the better performance
here is through mercilessly hogging ressources. In a complex database
environment with even larger tables, the performance gain in MS SQL would be
minimal (my guess).

Horst

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jean-Michel POURE 2001-10-31 05:41:56 Re: Serious performance problem
Previous Message mlw 2001-10-31 02:19:46 Re: with (iscachable)