| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Sergey Koposov <skoposov(at)cmu(dot)edu>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow |
| Date: | 2017-07-05 22:19:57 |
| Message-ID: | CAH2-Wzn19GKyEyNr3dXeazbBSstEEtaBO3MCQWwFqZs_bb52Zw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, Jul 5, 2017 at 3:14 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> Isn't an added conditional likely going to be more costly than the
> s/32/64/ bit calculations on the majority of machines pg runs on? I'm
> quite doubtful that it's worth catering for the few cases where that's
> really slow.
I doubt that myself. Especially prior to Postgres 10, where merging
will have tuplesort_heap_insert() as the bottleneck.
In Postgres 10, tuplesort external sort run merging became much faster
following commit 24598337c8d. It might be noticeable if such a machine
were using Postgres 10 already, and really had something to lose, but
that seems very unlikely.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2017-07-05 22:35:30 | Re: BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow |
| Previous Message | Andres Freund | 2017-07-05 22:14:14 | Re: BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow |