| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | James Coleman <jtc331(at)gmail(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>, Shaun Thomas <shaun(dot)thomas(at)2ndquadrant(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |
| Date: | 2019-06-25 17:13:39 |
| Message-ID: | CAH2-Wz=ptCW_dnRi3z4n8eUCzc82Y2qsd9ReWLr0-nxfhh=Hsg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jun 25, 2019 at 9:53 AM James Coleman <jtc331(at)gmail(dot)com> wrote:
> Given the patch contents I don't see any obviously reason why either
> of those possibilities (calling comparetup_heap less often, or it's
> cheaper) are likely. Is that something we should investigate further?
> Or is it just a nice happy accident that we should ignore since it's
> dataset specific?
Have you actually confirmed that comparetup_heap() is called less
often, by instrumenting the number of individual calls specifically?
If there has been a reduction in calls to comparetup_heap(), then
that's weird, and needs to be explained. If it turns out that it isn't
actually called less often, then I would suggest that the speedup
might be related to memory fragmentation, which often matters a lot
within tuplesort.c. (This is why external sort merging now uses big
buffers, and double buffering.)
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | James Coleman | 2019-06-25 18:03:28 | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |
| Previous Message | James Coleman | 2019-06-25 16:52:45 | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |