Skip site navigation (1) Skip section navigation (2)

Re: sub select performance due to seq scans

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rod Taylor <rbt(at)rbt(dot)ca>
Cc: H Hale <hhale21(at)rogers(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: sub select performance due to seq scans
Date: 2006-07-31 12:53:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Rod Taylor <rbt(at)rbt(dot)ca> writes:
>> Nested Loop IN Join  (cost=0.00..1386.45 rows=5809 width=14) (actual
>> time=2.933..101467.463 rows=5841 loops=1)
>> Join Filter: ("outer".objectid = "inner".dstobj)
>> ->  Seq Scan on flatomfilesysentry  (cost=0.00..368.09 rows=5809
>> width=30) (actual time=0.007..23.451 rows=5844 loops=1)
>> ->  Seq Scan on flatommemberrelation  (cost=0.00..439.05 rows=5842
>> width=16) (actual time=0.007..11.790 rows=2922 loops=5844)

> A loop for an IN indicates that you are using a very old version of
> PostgreSQL (7.2 or earlier).

No, it's not that, because 7.2 certainly had no idea of "IN Join"s.
But there's something mighty fishy about this plan anyway.  The
planner was predicting 5809 rows out from flatomfilesysentry (not
too far off), so why didn't it predict something north of
368.09 + 5809 * 439.05 as the total join cost?  There's a special case
in cost_nestloop for IN joins, but it sure shouldn't have reduced the
estimate by a factor of 1800+ ...

			regards, tom lane

In response to

pgsql-performance by date

Next:From: Michael StoneDate: 2006-07-31 13:30:37
Subject: Re: directory tree query with big planner variation
Previous:From: Jonathan BalletDate: 2006-07-31 12:53:24
Subject: Performances with new Intel Core* processors

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group