Re: The plan changes when the limit gets above ~850,000

From: "Wm(dot)A(dot)Stafford" <stafford(at)marine(dot)rutgers(dot)edu>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: The plan changes when the limit gets above ~850,000
Date: 2008-10-07 19:00:15
Message-ID: 48EBB1BF.9040900@marine.rutgers.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Tom,

Thanks for the reply. You are correct, I don't really care about
the behavior at less than the maximum number of rows. I guess I was
just a bit mystified by the difference in behavior. As of now, I stop
worrying about it.

-=beeky

Tom Lane wrote:
> "Wm.A.Stafford" <stafford(at)marine(dot)rutgers(dot)edu> writes:
>
>> I looked at the plan for both versions of the query and, as Albe
>> suggested, the plans were different. I don't know how to analyze the
>> plans but I'm guessing that when the number of records returned gets
>> larger setup time is an increasingly smaller part of the entire process
>> so more time can be spent on setup. This would result in the apparent
>> inactivity of the application running the query when limit went from
>> 850,000 to 1,000,000
>>
>
> Yeah, it's supposed to do that. The question you really need to be
> asking is what's the total elapsed time to do the whole query. If
> there's a serious slowdown then the planner is choosing to cut over
> too soon, which could probably be improved by fooling with the cost
> parameter.
>
> But, do you really care about the behavior with intermediate LIMIT
> values? I would think that you might have a small limit on this query
> while doing testing, but when you go to do the real data processing
> you won't have a LIMIT at all.
>
> regards, tom lane
>

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Kris Jurka 2008-10-08 18:48:12 SQLXML support
Previous Message Tom Lane 2008-10-07 16:13:19 Re: The plan changes when the limit gets above ~850,000