Re: table partitioning and select max(id) - Mailing list pgsql-performance

From Tobias Brox
Subject Re: table partitioning and select max(id)
Date
Msg-id AANLkTimU90yx4NEvHRE+otSDjWCDmG5Zjyhxecr-AGZ5@mail.gmail.com
Whole thread Raw
In response to Re: table partitioning and select max(id)  (Greg Smith <greg@2ndquadrant.com>)
Responses Re: table partitioning and select max(id)
List pgsql-performance
[Greg Smith]
> Here's the comment from that describing the main technique used to fix it:
>
> "This module tries to replace MIN/MAX aggregate functions by subqueries of
> the form
>
> (SELECT col FROM tab WHERE ... ORDER BY col ASC/DESC LIMIT 1)

Huh ... that sounds a bit like pg 8.0 to me ;-)  I remember on 7.x one
had to write "select id from table order by id desc limit 1" to force
through a quick index scan.  This was fixed in 8.0 IIRC.  I did test
"select id from table order by id desc limit 1" on my parent table
yesterday, it would still do the seq-scan.  Even adding a
where-restriction to make sure only one partition was queried I still
got the seq-scan.

> Unfortunately that change ends a series of 6 commits of optimizer
> refactoring in this area, so it's not the case that you just apply this one
> commit as a bug-fix to a 9.0 system.  I have a project in process to do the
> full backport needed I might be able to share with you if that works out,
> and you're willing to run with a customer patched server process.

In this particular case, "wait for 9.1" seems to be the best option :-)

pgsql-performance by date:

Previous
From: david@lang.hm
Date:
Subject: Re: getting the most of out multi-core systems for repeated complex SELECT statements
Next
From: Scott Marlowe
Date:
Subject: Re: [HACKERS] Slow count(*) again...