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)  (Peter Geoghegan <pg@heroku.com>)
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: rethinking dense_alloc (HashJoin) as a memory context
Следующее
От: Robert Haas
Дата:
Сообщение: Re: A Modest Upgrade Proposal