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

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]
Дата
Msg-id 003601cdfa1d$4a8fb520$dfaf1f60$@kapila@huawei.com
обсуждение исходный текст
Ответ на Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]  (Noah Misch <noah@leadboat.com>)
Список 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.kapila@huawei.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
295Run-5: 308         305  Avg  : 302.2      305.2
 


With Regards,
Amit Kapila.




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: [PATCH 0/3] Work around icc miscompilation
Следующее
От: Xi Wang
Дата:
Сообщение: Re: [PATCH 0/3] Work around icc miscompilation