Re: [HACKERS] [PATCH] Incremental sort

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Antonin Houska <ah(at)cybertec(dot)at>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] [PATCH] Incremental sort
Date: 2018-03-05 10:19:05
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers


I have started reviewing the patch and doing some testing, and I have
pretty quickly ran into a segfault. Attached is a simple reproducer and
an backtrace. AFAICS the bug seems to be somewhere in the tuplesort
changes, likely resetting a memory context too soon or something like
that. I haven't investigated it further, but it matches my hunch that
tuplesort is likely where the bugs will be.

Otherwise the patch seems fairly complete. A couple of minor things that
I noticed while eyeballing the changes in a diff editor.

1) On a couple of places the new code has this comment

/* even when not parallel-aware */

while all the immediately preceding blocks use

/* even when not parallel-aware, for EXPLAIN ANALYZE */

I suggest using the same comment, otherwise it kinda suggests it's not

2) I think the purpose of sampleSlot should be explicitly documented
(and I'm not sure "sample" is a good term here, as is suggest some sort
of sampling (for example nodeAgg uses grp_firstTuple).

3) skipCols/SkipKeyData seems a bit strange too, I think. I'd use
PresortedKeyData or something like that.

4) In cmpSortSkipCols, when checking if the columns changed, the patch
does this:

n = ((IncrementalSort *) node->>skipCols;

for (i = 0; i < n; i++)
... check i-th key ...

My hunch is that checking the keys from the last one, i.e.

for (i = (n-1); i >= 0; i--)

would be faster. The reasoning is that with "ORDER BY a,b" the column
"b" changes more often. But I've been unable to test this because of the
segfault crashes.

5) The changes from

if (pathkeys_contained_in(...))


n = pathkeys_common(pathkeys, subpath->pathkeys);

if (n == 0)

seem rather inconvenient to me, as it makes the code unnecessarily
verbose. I wonder if there's a better way to deal with this.


Tomas Vondra
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
plan.txt text/plain 504 bytes
crash.sql application/sql 250 bytes
backtrace.txt text/plain 2.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Edmund Horner 2018-03-05 10:21:28 Re: PATCH: psql tab completion for SELECT
Previous Message Daniel Gustafsson 2018-03-05 10:18:20 Re: Better Upgrades