> Greg Stark wrote:
> >I think part of the problem is that there's a bunch of features
> >these types of queries and the lines between them blur.
> >You seem to be talking about putting visibility information inside
> indexes for
> >so index-only plans can be performed. But you're also talking about
> >like "select count(*) from foo" with no where clauses. Such a query
> >be helped by index-only scans.
> >Perhaps you're thinking about caching the total number of records in
> >piece of state like a materialized view? That would be a nice feature
> >think it should done as a general materialized view implementation,
> >special case solution for just this one query.
> >Perhaps you're thinking of the min/max problem of being able to use
> indexes to
> >pick out just the tuples satisfying the min/max constraint. That
> >to be one of the more tractable problems in this area but it would
> >require lots of work.
> >I suggest you post a specific query you find is slow. Then discuss
> >think it ought to be executed and why.
> You are correct, I am proposing to add visibility to the indexes.
> As for unqualified counts, I believe that they could take advantage of
> an index-only scan as it requires much less I/O to perform an index
> than a sequential scan on large tables.
I agree with Greg...I think the way to approach this is a general
materialized view solution. This would solve a broad class of tricky
problems including count() and count(*)...you get to choice between the
pay now/pay later tradeoff, etc.
pgsql-hackers by date
|Next:||From: Jonah H. Harris||Date: 2005-01-12 19:52:53|
|Subject: Re: Much Ado About COUNT(*)|
|Previous:||From: Tom Lane||Date: 2005-01-12 19:41:56|
|Subject: Re: Much Ado About COUNT(*) |