From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: tuplesort.c's copytup_index() is dead code |
Date: | 2016-06-27 21:21:49 |
Message-ID: | 20160627212149.GA15923@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jun 24, 2016 at 02:26:18PM -0700, Peter Geoghegan wrote:
> On Fri, Jun 24, 2016 at 2:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Uh, why? It's not a large amount of code and it seems like removing
> > it puts a fair-size hole in the symmetry of tuplesort's capabilities.
>
> It's not a small amount of code either.
>
> Removing the code clarifies the division of labor between COPYTUP()
> routines in general, their callers (tuplesort_putheaptuple() and
> tuplesort_puttupleslot() -- which are also puttuple_common() callers),
> and routines that are similar to those caller routines (in that they
> at least call puttuple_common()) that do not call COPYTUP()
> (tuplesort_putdatum(), and now tuplesort_putindextuplevalues()).
>
> I believe that this has value. All the extra boilerplate code misleads.
At a minimum we can block out the code with #ifdef NOT_USED.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-06-27 21:28:56 | Re: fixing consider_parallel for upper planner rels |
Previous Message | Robert Haas | 2016-06-27 21:18:50 | Re: [HITB-Announce] HITB2016AMS Videos & GSEC Singapore Voting |