Re: Bad planner decision in Postgres
От | Matthew Wakeling |
---|---|
Тема | Re: Bad planner decision in Postgres |
Дата | |
Msg-id | Pine.LNX.4.58.0502011756070.8323@aragorn.flymine.org обсуждение исходный текст |
Ответ на | Re: Bad planner decision in Postgres (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
> Matthew Wakeling <mnw21@cam.ac.uk> writes: > > [ snip... ] > > If we remove the limit, then the planner switches to this query plan: > > > Limit (cost=156.24..156.26 rows=10 width=14) > > ... which still has a limit. I think you have made several cut-and-paste > errors here, because the plans you are exhibiting aren't legal for the > queries you say they are for. Nor do I see a reason that the planner > would use, eg, a Sort step for a query with no ORDER BY. Have you > perhaps been fooling with the various enable_xxx options to try to force > the planner to do what you think it should do? I'm sorry, yes they are cut-and-paste errors. I haven't fiddled with the enable_xxx options to get those results. The queries that I ran actually did have an order by clause (ordered on column), and that query you point out as having a limit is another copy-and-paste error - I used a limit with a large offset, which has an identical performance characteristic as having no limit. The problem stands, my copy-and-paste sucked. Matthew -- If pro is the opposite of con, what is the opposite of progress?
В списке pgsql-bugs по дате отправления: