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 :-)
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 |