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

Re: Optimizer internals

From: "John Vincent" <pgsql-performance(at)lusis(dot)org>
To: "Mark Lewis" <mark(dot)lewis(at)mir3(dot)com>
Cc: "PGSQL Performance" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Optimizer internals
Date: 2006-06-15 18:46:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On 6/15/06, Mark Lewis <mark(dot)lewis(at)mir3(dot)com> wrote:

> DB2 can satisfy the query using only indexes because DB2 doesn't do
> Although MVCC is generally a win in terms of making the database easier
> to use and applications less brittle, it also means that the database
> must inspect the visibility information for each row before it can
> answer a query.  For most types of queries this isn't a big deal, but
> for count(*) type queries, it slows things down.


Thanks for the answer. My DBAs just got this look on thier face when I
showed. It's not like the couldn't have investigated this information
themselves but I think the light finally came on.

One question that we came up with is how does this affect other aggregate
functions like MAX,MIN,SUM and whatnot? Being that this is our data
warehouse, we use these all the time. As I've said previously, I didn't know
a human could generate some of the queries we've passed through this system.

Since adding the visibility information to indexes would make them
> significantly more expensive to use and maintain, it isn't done.
> Therefore, each row has to be fetched from the main table anyway.
> Since in this particular query you are counting all rows of the
> database, PG must fetch each row from the main table regardless, so the
> sequential scan is much faster because it avoids traversing the index
> and performing random read operations.
> -- Mark Lewis

In response to


pgsql-performance by date

Next:From: Mark LewisDate: 2006-06-15 19:01:03
Subject: Re: Optimizer internals
Previous:From: Mark LewisDate: 2006-06-15 18:33:45
Subject: Re: Optimizer internals

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