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

From: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
To: "'Noah Misch'" <noah(at)leadboat(dot)com>, "'Simon Riggs'" <simon(at)2ndQuadrant(dot)com>
Cc: "'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: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]
Date: 2013-01-24 10:26:36
Message-ID: 003601cdfa1d$4a8fb520$dfaf1f60$@kapila@huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thursday, January 24, 2013 7:42 AM Noah Misch wrote:
> On Wed, Jan 09, 2013 at 11:22:06AM +0000, Simon Riggs wrote:
> > On 24 December 2012 16:57, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
> wrote:
> > > Performance: Average of 3 runs of pgbench in tps
> > > 9.3devel | with trailing null patch
> > > ----------+--------------------------
> > > 578.9872 | 573.4980
> >
> > 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.
> >
> > Do you have a reason why a different view might be taken?
>
> We've mostly ignored performance changes of a few percentage points,
> because
> the global consequences of adding or removing code to the binary image
> can
> easily change performance that much. It would be great to get to the
> point
> where we can reason about 1% performance changes, but we're not there.
> If a
> measured +1% performance change would have yielded a different
> decision, we
> should rethink the decision based on more-robust criteria.

Today, I had taken one more set of readings of original pg_bench which are
below in this mail. The difference is that this set of readings are on Suse
11 and with Shared buffers - 4G
IMO, the changes in this patch are not causing any regression, however it
gives performance/size reduction
in some of the cases as shown by data in previous mails.
So the point to decide is whether the usecases in which it is giving benefit
are worth to have this Patch?
As Tom had already raised some concern's about the code, I think the Patch
can only have merit if the usecase
makes sense to people.

System Configuration:
Hardware : 4 core (Intel(R) Xeon(R) CPU L5408 @ 2.13GHz) & RAM : 24GB
Operating System: Suse-Linux 11.2 x86_64

Sever Configuration:
The database cluster will be initialized with locales
COLLATE: C
CTYPE: C
MESSAGES: en_US.UTF-8
MONETARY: en_US.UTF-8
NUMERIC: en_US.UTF-8
TIME: en_US.UTF-8

shared_buffers = 4GB
checkpoint_segments = 255
checkpoint_timeout = 10min

pgbench:
transaction type: TPC-B (sort of)
scaling factor: 75
query mode: simple
number of clients: 4
number of threads: 4
duration: 300 s

original patch
Run-1: 311 312
Run-2: 307 302
Run-3: 300 312
Run-4: 285 295
Run-5: 308 305

Avg : 302.2 305.2

With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Xi Wang 2013-01-24 10:30:58 Re: [PATCH 0/3] Work around icc miscompilation
Previous Message Heikki Linnakangas 2013-01-24 10:02:09 Re: [PATCH 0/3] Work around icc miscompilation