Postgres Professional
   

Re: Weird performance drop after VACUUM

From: Steinar H. Gunderson
Subject: Re: Weird performance drop after VACUUM
Date: ,
Msg-id: 20050827152603.GF17097@uio.no
(view: Whole thread, Raw)
In response to: Weird performance drop after VACUUM  (Ümit Öztosun)
Responses: Re: Weird performance drop after VACUUM  (Tom Lane)
List: pgsql-performance

Tree view

Weird performance drop after VACUUM  (Ümit Öztosun, )
 Re: Weird performance drop after VACUUM  (asif ali, )
  Re: Weird performance drop after VACUUM  (Philip Hallstrom, )
  Re: Weird performance drop after VACUUM  (Michael Fuhr, )
   Re: Weird performance drop after VACUUM  (asif ali, )
    Re: Weird performance drop after VACUUM  (Michael Fuhr, )
     Re: Weird performance drop after VACUUM  (asif ali, )
      Re: Weird performance drop after VACUUM  (Michael Fuhr, )
       Re: Weird performance drop after VACUUM  (asif ali, )
 Re: Weird performance drop after VACUUM  (Tom Lane, )
  Re: Weird performance drop after VACUUM  (Umit Oztosun, )
  Re: Weird performance drop after VACUUM  ("Steinar H. Gunderson", )
   Re: Weird performance drop after VACUUM  (Tom Lane, )
 Re: Weird performance drop after VACUUM  ("Steinar H. Gunderson", )
  Re: Weird performance drop after VACUUM  (Tom Lane, ) 
On Sat, Aug 27, 2005 at 11:05:01AM -0400, Tom Lane wrote:
> It could, but it doesn't really have enough information.  We don't
> currently have any model that some operators are more expensive than
> others.  IIRC the only sort of reordering the current code will do
> in a filter condition list is to push clauses involving sub-SELECTs
> to the end.

I was more thinking along the lines of reordering "a AND/OR b" to "b AND/OR
a" if b has lower selectivity than a.

/* Steinar */
--
Homepage: http://www.sesse.net/

pgsql-performance by date:

Previous:
From: Tom Lane
Date:
Subject: Re: Weird performance drop after VACUUM
Next:
From: Tom Lane
Date:
Subject: Re: Limit + group + join