From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Jonathan <jonathan(at)kc8onw(dot)net> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Slow query when using ORDER BY *and* LIMIT |
Date: | 2011-07-09 03:39:14 |
Message-ID: | CAFj8pRBM_XMv0qZ0DheekEQKQfnSCtmOgNHenUXmudLe9hpsoA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hello
Is impossible to help you without more detailed info about your problems,
we have to see a execution plan, we have to see slow query
Regards
Pavel Stehule
2011/7/9 Jonathan <jonathan(at)kc8onw(dot)net>:
> Does anyone have any suggestions for my problem? (I have to wonder if I'm
> somehow just not getting peoples attention or what. This is my second
> question this week on a public mailing list that has gotten exactly 0
> replies)
>
> Jonathan
>
> On 7/5/2011 8:18 PM, Jonathan wrote:
>>
>> I have a query that uses ORDER BY and LIMIT to get a set of image data
>> rows that match a given tag. When both ORDER BY and LIMIT are included
>> for some reason the planner chooses a very slow query plan. Dropping one
>> or the other results in a much faster query going from 4+ seconds -> 30
>> ms. Database schema, EXPLAIN ANALYZE and other information can be found
>> at http://pgsql.privatepaste.com/31113c27bf Is there a way to convince
>> the planner to use the faster plan when doing both ORDER BY and LIMIT
>> without using SET options or will I need to disable the slow plan
>> options to force the planner to use the fast plan?
>>
>> I found some stuff in the mailing list archives that looks related but I
>> didn't see any fixes. Apparently the planner hopes the merge join will
>> find the LIMIT # of rows fairly quickly but instead it winds up scanning
>> almost the entire table.
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2011-07-09 03:49:34 | Re: Slow query when using ORDER BY *and* LIMIT |
Previous Message | Clem Dickey | 2011-07-09 01:33:15 | Re: GROUP BY with reasonable timings in PLAN but unreasonable execution time |