Re: Searching for the cause of a bad plan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Csaba Nagy <nagy(at)ecircle-ag(dot)com>
Cc: postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Searching for the cause of a bad plan
Date: 2007-09-21 16:08:33
Message-ID: 6175.1190390913@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Csaba Nagy <nagy(at)ecircle-ag(dot)com> writes:
> Looking at Plan 2, it looks like the "limit" step is estimating wrongly
> it's cost.

The reason you get a bad plan is that this rowcount estimate is so far
off:

> -> Index Scan using pk_table_a on table_a ta (cost=0.00..324786.18 rows=388532 width=16) (actual time=454.389..460.138 rows=2 loops=1)
> Index Cond: (a = $1)

Raising the stats target helped no doubt because it didn't overestimate
the number of rows so much...

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Grittner 2007-09-21 16:35:15 Re: query io stats and finding a slow query
Previous Message Csaba Nagy 2007-09-21 15:48:09 Re: Searching for the cause of a bad plan