[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgsql-performance
Subject:    Re: [PERFORM] Yet another slow nested loop
From:       Robert Haas <robertmhaas () gmail ! com>
Date:       2009-06-17 4:59:13
Message-ID: 603c8f070906162159t1a80708dg5de9acc19823894d () mail ! gmail ! com
[Download RAW message or body]

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

-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance


[prev in list] [next in list] [prev in thread] [next in thread]