Re: after vacuum analyze, explain still wrong

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>
Cc: Sim Zacks <sim(at)compulab(dot)co(dot)il>, pgsql-general(at)postgresql(dot)org
Subject: Re: after vacuum analyze, explain still wrong
Date: 2009-06-23 14:43:59
Message-ID: 407d949e0906230743r1317902cv84398395aa6c7b22@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Actually most of the estimates seem pretty good. There are some that
are a ways off, but the real nasties seem to be these. I'm a bit
confused because it looks like two of your joins don't have Join
Filters -- and one of those is a left join for which I thought that
was impossible.

Are you sure this query is doing what you expect? You have
add_missing_from enabled which will happily bring in additional joins
if you reference a table which isn't already included in the join and
do a full cartesian-product join.

-> Nested Loop
Left Join (cost=145.04..2381.33 rows=1 width=74) (actual
time=38.955..9678.057 rows=3754 loops=1)
Join
Filter: ((c.partid = e.partid) AND leadcompcheck_ab(a.leadfree,
c.leadstateid))
-> Nested
Loop (cost=145.04..2366.26 rows=1 width=62) (actual time=0.791..83.482
rows=3754 loops=1)
->
Nested Loop Left Join (cost=145.04..2365.59 rows=1 width=28) (actual
time=0.721..52.840 rows=3754 loops=1)

Filter: (f.commited IS NOT TRUE)

--
greg
http://mit.edu/~gsstark/resume.pdf

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message DaNieL..! 2009-06-23 14:44:13 Re: Please suggest me on my table design (indexes!)
Previous Message Tom Lane 2009-06-23 14:36:23 Re: Information about columns