Re: Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]

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

In response to

Responses

Browse pgsql-hackers by date

  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