From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, Kevin Grittner <kgrittn(at)mail(dot)com>, robertmhaas(at)gmail(dot)com, josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org, jameisonb(at)yahoo(dot)com |
Subject: | Re: Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review] |
Date: | 2013-01-24 04:13:33 |
Message-ID: | 25975.1359000813@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Noah Misch <noah(at)leadboat(dot)com> writes:
> On Wed, Jan 09, 2013 at 11:22:06AM +0000, Simon Riggs wrote:
>> On balance, it would seem optimizing for this special case would
>> affect everybody negatively; not much, but enough. Which means we
>> should rekect this patch.
> I've failed to come up with a non-arbitrary reason to recommend for or against
> this patch, so I profess neutrality on the ultimate issue.
I think if we can't convincingly show an attractive performance gain,
we should reject the patch on the grounds of added complexity. Now,
the amount of added code surely isn't much, but nonetheless this patch
eliminates an invariant that's always been there (ie, that a tuple's
natts matches the tupdesc it was built with). That will at the very
least complicate forensic work, and it might well break third-party
code, or corners of the core system that we haven't noticed yet.
I'd be okay with this patch if it had more impressive performance
results, but as it is I think we're better off without it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-01-24 04:32:24 | Re: [sepgsql 1/3] add name qualified creation label |
Previous Message | Ashutosh Bapat | 2013-01-24 03:35:59 | Re: pg_ctl idempotent option |