On Fri, Jun 24, 2016 at 02:26:18PM -0700, Peter Geoghegan wrote:
> On Fri, Jun 24, 2016 at 2:18 PM, Tom Lane 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 cod
On Fri, Jun 24, 2016 at 2:18 PM, Tom Lane 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 COPYTU
Peter Geoghegan writes:
> On Thu, Jun 23, 2016 at 7:59 PM, Tom Lane wrote:
>> I think this may be premature in view of bug #14210. Even if we
>> don't reinstate use of this function to fix that, I'm not really
>> convinced we want to get rid of it; it seems likely to me that
>> we might want it
On Thu, Jun 23, 2016 at 7:59 PM, Tom Lane wrote:
> I think this may be premature in view of bug #14210. Even if we
> don't reinstate use of this function to fix that, I'm not really
> convinced we want to get rid of it; it seems likely to me that
> we might want it again.
You pushed a fix for bu
On Thu, Jun 23, 2016 at 8:35 PM, Tom Lane wrote:
> We *do* have regression test coverage, but that code is set up to not
> kick in at any index scale that would be sane to test in the regression
> tests. See
> https://www.postgresql.org/message-id/12194.1466724...@sss.pgh.pa.us
I'm well aware of
Peter Geoghegan writes:
> FWIW, I think that that bug tells us a lot about hash index usage in
> the field. It took many months for someone to complain about what
> ought to have been a really obvious bug. Clearly, hardly anybody is
> using hash indexes. I broke hash index tuplesort builds in a si
On Thu, Jun 23, 2016 at 7:59 PM, Tom Lane wrote:
> I think this may be premature in view of bug #14210. Even if we
> don't reinstate use of this function to fix that, I'm not really
> convinced we want to get rid of it; it seems likely to me that
> we might want it again.
Oh, yes; that involves
Peter Geoghegan writes:
> Commit 9f03ca915 removed the only COPYTUP() call that could reach
> copytup_index() in practice, making copytup_index() dead code.
> The attached patch removes this dead code,
I think this may be premature in view of bug #14210. Even if we
don't reinstate use of this f
Commit 9f03ca915 removed the only COPYTUP() call that could reach
copytup_index() in practice, making copytup_index() dead code.
The attached patch removes this dead code, in line with the existing
copytup_datum() case, where tuplesort.c also doesn't directly support
COPYTUP() (due to similar cons
