Re: Bug in batch tuplesort memory CLUSTER case (9.6 only)
От | Tom Lane |
---|---|
Тема | Re: Bug in batch tuplesort memory CLUSTER case (9.6 only) |
Дата | |
Msg-id | 26274.1468435455@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Bug in batch tuplesort memory CLUSTER case (9.6 only) (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: Bug in batch tuplesort memory CLUSTER case (9.6 only)
|
Список | 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 по дате отправления: