pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Scott Marlowe <smarlowe@g2switchworks.com>
To: pgsql-performance@lusis.org
Cc: Mark Lewis <mark.lewis@mir3.com>
Cc: PGSQL Performance <pgsql-performance@postgresql.org>
Subject: Re: Optimizer internals
Date: Thu, 15 Jun 2006 14:26:39 -0500
Message-ID: <1150399599.26538.90.camel@state.g2switchworks.com> (raw)
In-Reply-To: <c841561b0606151221v219987aap376194583dd30940@mail.gmail.com>
References: <c841561b0606151105v459d830era158b9eea5f59a7e@mail.gmail.com>
	<1150396425.31200.66.camel@archimedes>
	<c841561b0606151146j5f8410f2qaeaff7649b70cd20@mail.gmail.com>
	<1150398064.31200.76.camel@archimedes>
	<c841561b0606151221v219987aap376194583dd30940@mail.gmail.com>

On Thu, 2006-06-15 at 14:21, John Vincent wrote:
> 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? 

This might help:

http://jonathangardner.net/PostgreSQL/materialized_views/matviews.html

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



view thread (17+ messages)  latest in thread

Message-ID: <1150399599.26538.90.camel@state.g2switchworks.com>
Permalink:  ../1150399599.26538.90.camel@state.g2switchworks.com/
Also on:    postgresql.org/message-id/1150399599.26538.90.camel@state.g2switchworks.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: smarlowe@g2switchworks.com, pgsql-performance@lusis.org, mark.lewis@mir3.com
  Subject: Re: Optimizer internals
  In-Reply-To: <1150399599.26538.90.camel@state.g2switchworks.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox