I wrote:
> I am thinking that a cleaner fix is probably to make ExecRescanLimit do
> the recompute_limits() bit immediately, so that the new limits are
> available to the Sort node when it gets the rescan call. The comment
> about timing of recompute_limits() is referring to the fact that
> parame
Gregory Stark <[EMAIL PROTECTED]> writes:
> It doesn't look like the timing of the ExecRescan is an issue at all. There
> are plenty of nodes that Rescan their children much later than when they first
> start up. Even Nested Loop does so.
Right, but separating the child rescan from the tuplestore
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
>> This patch makes what was already a hack into a full-fledged crock (and
>> it's not just the self-doubting comments that make me distrust it).
>> I think we need to rip out this ad-hoc parameter change signal
"Tom Lane" <[EMAIL PROTECTED]> writes:
> This patch makes what was already a hack into a full-fledged crock (and
> it's not just the self-doubting comments that make me distrust it).
> I think we need to rip out this ad-hoc parameter change signaling code
> and make it work through the regular chg
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> [ greps a bit... ] It looks like the only way that you could expose the
>> bug in the current state of the system would be if the sort/limit with
>> the outer parameter were the inside of a nestloop join in the s
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>
>> Attached is a small patch which fixes this case. It also makes the check
>> slightly more liberal -- we don't need to resort if the previous sort was
>> unbounded or the bound was greater than or equal to the new bound.
>
> H
Gregory Stark wrote:
> Attached is a small patch which fixes this case. It also makes the check
> slightly more liberal -- we don't need to resort if the previous sort was
> unbounded or the bound was greater than or equal to the new bound.
Huh, can you clarify this comment:
+* XXX It wo
"Tom Lane" <[EMAIL PROTECTED]> writes:
> [ greps a bit... ] It looks like the only way that you could expose the
> bug in the current state of the system would be if the sort/limit with
> the outer parameter were the inside of a nestloop join in the subplan.
> nodeNestloop would set EXEC_FLAG_RE
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Look at the chgParam signaling. Since a Sort node itself has no
>> parameters, it historically has only had to re-sort if its input node
>> suffers a parameter change, which it checks in ExecReScanSort. But now
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> What does the executor do differently in the case of a subplan with a
>> parameter that makes it re-execute the plan from scratch and not just do a
>> simple rescan?
>
> Look at the chgParam signaling. Since a S
Gregory Stark <[EMAIL PROTECTED]> writes:
> Hum. The major change I see is the bit related to rescans where you made it
> resort if the bound had changed. But surely the only way the bound can change
> is if it's a parameter, and if there is a parameter then surely the executor
> must be doing more
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Updated patch against cvs update in case it makes applying easier.
>
> Applied with revisions --- notably, I avoided adding any overhead to
> HEAPCOMPARE() by the expedient of reversing the logical sort order
> b
Gregory Stark <[EMAIL PROTECTED]> writes:
> Updated patch against cvs update in case it makes applying easier.
Applied with revisions --- notably, I avoided adding any overhead to
HEAPCOMPARE() by the expedient of reversing the logical sort order
before heapify'ing. We couldn't have done that bef
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Gr
Updated patch against cvs update in case it makes applying easier.
One minor change:
. Added #include in tuplesort.h to pull in UINT_MAX
(thanks to dpage for noticing this is necessary on OSX)
sort-limit-v8.patch.gz
Description: Binary data
--
Gregory Stark
EnterpriseDB htt
15 matches
Mail list logo
