Re: Searching for the cause of a bad plan
От | Csaba Nagy |
---|---|
Тема | Re: Searching for the cause of a bad plan |
Дата | |
Msg-id | 1190376744.4661.208.camel@PCD12478 обсуждение исходный текст |
Ответ на | Re: Searching for the cause of a bad plan (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Searching for the cause of a bad plan
|
Список | pgsql-performance |
On Fri, 2007-09-21 at 12:34 +0100, Simon Riggs wrote: > On Fri, 2007-09-21 at 13:29 +0200, Csaba Nagy wrote: > > > > Can you plans with/without LIMIT and with/without cursor, for both b1 > > > and b2? > > > > The limit is unfortunately absolutely needed part of the query > > Understood, but not why I asked... > Well, the same query without limit goes: dbdop=# explain execute test_001(31855344); QUERY PLAN ------------------------------------------------------------------------------------------------------------ Sort (cost=322831.85..322831.94 rows=36 width=1804) Sort Key: ta.a, ta.b -> Hash Join (cost=3365.60..322830.92 rows=36 width=1804) Hash Cond: (ta.b = tb.b) -> Index Scan using pk_table_a on table_a ta (cost=0.00..314541.78 rows=389648 width=16) Index Cond: (a = $1) -> Hash (cost=524.71..524.71 rows=41671 width=1788) -> Seq Scan on table_b2 tb (cost=0.00..524.71 rows=41671 width=1788) I'm not sure what you mean without cursor, maybe not using prepare ? Well we set up the JDBC driver to always prepare the queries, as this gives us much better worst case plans than when letting postgres see the parameter values, especially in queries with limit. So I simulate that when explaining the behavior we see. All our limit queries are for interactive display, so the worst case is of much higher importance for us than the mean execution time... unfortunately postgres has a tendency to take the best mean performance path than avoid worst case, and it is not easy to convince it otherwise. Cheers, Csaba.
В списке pgsql-performance по дате отправления: