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

Re: Optimizer internals

From: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
To: pgsql-performance(at)lusis(dot)org
Cc: Mark Lewis <mark(dot)lewis(at)mir3(dot)com>, PGSQL Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Optimizer internals
Date: 2006-06-15 19:26:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Thu, 2006-06-15 at 14:21, John Vincent wrote:
> On 6/15/06, Mark Lewis <mark(dot)lewis(at)mir3(dot)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? 

This might help:

Since you're doing a data warehouse, I would think materialized views
would be a natural addition anyway.

In response to

pgsql-performance by date

Next:From: John VincentDate: 2006-06-15 19:38:32
Subject: Re: Optimizer internals
Previous:From: John VincentDate: 2006-06-15 19:21:50
Subject: Re: Optimizer internals

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