Re: table partitioning and select max(id)

From: Tobias Brox <tobixen(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: table partitioning and select max(id)
Date: 2011-02-05 08:16:09
Message-ID: AANLkTimU90yx4NEvHRE+otSDjWCDmG5Zjyhxecr-AGZ5@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 :-)

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Marlowe 2011-02-05 08:38:40 Re: [HACKERS] Slow count(*) again...
Previous Message david 2011-02-05 07:15:52 Re: getting the most of out multi-core systems for repeated complex SELECT statements