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 signaling code
and
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
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
parameters
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
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.
Huh, can you
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 subplan.
I
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 chgParam
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_REWIND,
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
before
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 than
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
the bound
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
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.
---
Updated patch against cvs update in case it makes applying easier.
One minor change:
. Added #include limits.h 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
14 matches
Mail list logo
