Re: Postgres 8.3, four times slower queries?

From: Tom Lane
Subject: Re: Postgres 8.3, four times slower queries?
Date: ,
Msg-id: 17797.1236119652@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: Postgres 8.3, four times slower queries?  (Aaron Guyon)
Responses: Re: Postgres 8.3, four times slower queries?  (Aaron Guyon)
List: pgsql-performance

Tree view

Postgres 8.3, four times slower queries?  (Aaron Guyon, )
 Re: Postgres 8.3, four times slower queries?  (Tom Lane, )
  Re: Postgres 8.3, four times slower queries?  (Aaron Guyon, )
   Re: Postgres 8.3, four times slower queries?  (, )
    Re: Postgres 8.3, four times slower queries?  (Aaron Guyon, )
   Re: Postgres 8.3, four times slower queries?  (Tom Lane, )
    Re: Postgres 8.3, four times slower queries?  (Aaron Guyon, )
     Re: Postgres 8.3, four times slower queries?  (Aaron Guyon, )
     Re: Postgres 8.3, four times slower queries?  (Aaron Guyon, )
      Re: Postgres 8.3, four times slower queries?  (Aaron Guyon, )
       Re: Postgres 8.3, four times slower queries?  ("Kevin Grittner", )
        Re: Postgres 8.3, four times slower queries?  (Robert Haas, )
     Re: Postgres 8.3, four times slower queries?  (Robert Haas, )
 Re: Postgres 8.3, four times slower queries?  (Robert Haas, )
 Re: Postgres 8.3, four times slower queries?  (Aaron Guyon, )
 Re: Postgres 8.3, four times slower queries?  (Aaron Guyon, )

Aaron Guyon <> writes:
> I find it telling that the query plan differs so much between postgres 8.2.

Well, you haven't shown us either the query or the table definitions,
so we're just guessing in the dark.  However, the occurrences of
"::numeric" in the query plan make me wonder whether all of your join
keys are numeric type.  If so, the reason 8.2 didn't use any hash joins
is that it couldn't --- it didn't have a hash method for numerics.  8.3
does and therefore has more flexibility of plan choice.  Comparisons on
numerics aren't terribly fast though (in either release).  I wonder
whether you could change the key columns to int or bigint.

I also find it a tad fishy that both releases are choosing *exactly* the
same join order when there is hardly anything else that is identical
about the plans --- given the cross-release variance in rowcount
estimates etc I'd have expected at least one difference.  Are you doing
something to force the join order, like running with a small
join_collapse_limit setting?  If so maybe you shouldn't.

            regards, tom lane


pgsql-performance by date:

From: Scott Marlowe
Date:
Subject: Re: work_mem in high transaction rate database
From: Akos Gabriel
Date:
Subject: Re: work_mem in high transaction rate database