Re: Optimizer internals - Mailing list pgsql-performance

From John Vincent
Subject Re: Optimizer internals
Date
Msg-id c841561b0606151221v219987aap376194583dd30940@mail.gmail.com
Whole thread Raw
In response to Re: Optimizer internals  (Mark Lewis <mark.lewis@mir3.com>)
Responses Re: Optimizer internals  (Scott Marlowe <smarlowe@g2switchworks.com>)
Re: Optimizer internals  ("John Vincent" <pgsql-performance@lusis.org>)
Re: Optimizer internals  ("John Vincent" <lusis.org@gmail.com>)
List pgsql-performance
On 6/15/06, Mark Lewis <mark.lewis@mir3.com> wrote:

Unfortunately SUM is in the same boat as COUNT; in order for it to
return a meaningful result it must inspect visibility information for
all of the rows.

-- Mark

We'll this is interesting news to say the least. We went with PostgreSQL for our warehouse because we needed the advanced features that MySQL didn't have at the time (views/sprocs).

It sounds like we almost need another fact table for the places that we do SUM (which is not a problem just an additional map. If I'm interpreting this all correctly, we can't force PG to bypass a sequence scan even if we know our data is stable because of the MVCC aspect. In our case, as with most warehouses (except those that do rolling loads during the day), we only write data to it for about 5 hours at night in batch.

Any suggestions? FYI the original question wasn't meant as a poke at comparing PG to MySQL to DB2. I'm not making an yvalue judgements either way. I'm just trying to understand how we can use it the best way possible.

If anyone from the bizgres team is watching, have they done any work in this area?

Thanks.
John

pgsql-performance by date:

Previous
From: Mark Lewis
Date:
Subject: Re: Optimizer internals
Next
From: Scott Marlowe
Date:
Subject: Re: Optimizer internals