Re: 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: "'Jameison Martin'" <jameisonb(at)yahoo(dot)com>
Cc: "'Kevin Grittner'" <kgrittn(at)mail(dot)com>, "'Simon Riggs'" <simon(at)2ndQuadrant(dot)com>, <robertmhaas(at)gmail(dot)com>, <josh(at)agliodbs(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]
Date: 2013-01-23 10:19:42
Message-ID: 00d801cdf953$29b741d0$7d25c570$@kapila@huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wednesday, January 23, 2013 2:30 AM Jameison Martin wrote:

> Sorry for the late response, I just happened to see this yesterday.

> Running a general benchmark against the patch as Keven suggests is a good
idea. 

> Amit, can you supply the actual values you saw when running pgbench (the 3
values for each run)? I'd like to verify
> that the 1% difference isn't due to some file system/OS variability (would
be interested in what the stdev is for the
> values). Also, do you happen to have some information about the hardware
you ran on?

Performance data for 5 runs is as below:

System Configuration:
Hardware : 4 core (Intel(R) Xeon(R) CPU L5408 @ 2.13GHz) & RAM : 24GB
Operating System: Suse-Linux 10.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 = 2GB
checkpoint_segments = 255
checkpoint_timeout = 10min

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

original patch
Run-1: 579.596730 570.212601
Run-2: 577.220325 576.719402
Run-3: 571.792736 574.118542
Run-4: 573.376879 571.548136
Run-5: 573.469166 576.321368

Avg : 575.091167 573.784009

With Regards,
Amit Kapila.

On Monday, December 24, 2012 7:58 PM Kevin Grittner wrote:
Simon Riggs wrote:

Not really sure about the 100s of columns use case.

But showing gain in useful places in these more common cases wins
my vote.

Thanks for testing. Barring objections, will commit.
Do we have any results on just a plain, old stock pgbench run, with
the default table definitions?

That would be a reassuring complement to the other tests.
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 = 1GB
checkpoint_segments = 255
checkpoint_timeout = 15min

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

Performance: Average of 3 runs of pgbench in tps
9.3devel | with trailing null patch
----------+--------------------------
578.9872 | 573.4980

With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2013-01-23 11:03:53 Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
Previous Message Dimitri Fontaine 2013-01-23 09:57:52 Re: Event Triggers: adding information