Re: Yet another slow nested loop

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

In response to

Browse pgsql-performance by date

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