Re: Yet another slow nested loop - Mailing list pgsql-performance

From Robert Haas
Subject Re: Yet another slow nested loop
Date
Msg-id 603c8f070906162159t1a80708dg5de9acc19823894d@mail.gmail.com
Whole thread Raw
In response to Re: Yet another slow nested loop  (Alexander Staubo <alex@bengler.no>)
List pgsql-performance
On Tue, Jun 16, 2009 at 11:16 AM, Alexander Staubo<alex@bengler.no> wrote:
> On Tue, Jun 16, 2009 at 4:36 PM, Tom Lane<tgl@sss.pgh.pa.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

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: High cost of ... where ... not in (select ...)
Next
From: Scott Marlowe
Date:
Subject: Re: Index Scan taking long time