Re: Bug in batch tuplesort memory CLUSTER case (9.6 only) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bug in batch tuplesort memory CLUSTER case (9.6 only)
Date
Msg-id 26274.1468435455@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bug in batch tuplesort memory CLUSTER case (9.6 only)  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Bug in batch tuplesort memory CLUSTER case (9.6 only)  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
Peter Geoghegan <pg@heroku.com> writes:
> Attached patch adds a CLUSTER external sort test case to the
> regression tests, as discussed.

I took a quick look at this patch.

> This makes a hardly noticeable difference on the run time of the
> CLUSTER tests, at least for me. Consider the following:

I tried the patch on prairiedog's host.  That's not the slowest
machine in the buildfarm, but it's right down there.  The patch
increases the runtime of the "cluster" test from ~1 sec to ~3 sec,
which I agree is pretty negligible (total time for the standard
regression tests is ~5 min on this machine).  That seems a cheap
price to pay for a significant improvement in code coverage.

What I don't much like is that it enlarges cluster.out with 200K of
random-looking, hard-to-manually-verify data.  May I suggest that
we replace the SELECTs with

select * from
(select hundred, lag(hundred) over () as lhundred,       thousand, lag(thousand) over () as lthousand,       tenthous,
lag(tenthous)over () as ltenthous from clstr_4) ss
 
where row(hundred, thousand, tenthous) <= row(lhundred, lthousand, ltenthous);hundred | lhundred | thousand | lthousand
|tenthous | ltenthous 
 
---------+----------+----------+-----------+----------+-----------
(0 rows)

If you're good with that adjustment, I'm happy to commit this.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: rethinking dense_alloc (HashJoin) as a memory context
Next
From: Robert Haas
Date:
Subject: Re: A Modest Upgrade Proposal