From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Alexander Staubo <alex(at)bengler(dot)no> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Yet another slow nested loop |
Date: | 2009-06-17 04:59:13 |
Message-ID: | 603c8f070906162159t1a80708dg5de9acc19823894d@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Jun 16, 2009 at 11:16 AM, Alexander Staubo<alex(at)bengler(dot)no> wrote:
> On Tue, Jun 16, 2009 at 4:36 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Actually the easiest way to fix that is to get rid of the LIMIT.
>> (Maybe use a cursor instead, and fetch only twenty rows.) LIMIT
>> magnifies the risks from any estimation error, and you've got a lot
>> of that here ...
>
> There's no cursor support in ActiveRecord, the ORM library we use, and
> I'm not going to write it. Anyway, I would prefer not to gloss over
> the underlying problem with something that requires a "TODO" next to
> it. What can be done to fix the underlying problem? Nothing?
Basically, we need a system that can accurately estimate multi-column
selectivity, or else some kind of planner hints.
http://archives.postgresql.org/pgsql-performance/2009-06/msg00023.php
http://archives.postgresql.org/pgsql-performance/2009-06/msg00119.php
(with apologies for linking to my own posts, but you can go back and
read the whole thread if you're interested)
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2009-06-17 05:12:48 | Re: Index Scan taking long time |
Previous Message | Tom Lane | 2009-06-17 04:06:18 | Re: High cost of ... where ... not in (select ...) |