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: "'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>
Subject: Re: Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]
Date: 2013-01-10 09:25:17
Message-ID: 006b01cdef14$67e11100$37a33300$@kapila@huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wednesday, January 09, 2013 5:45 PM Simon Riggs wrote:
> On 9 January 2013 12:06, Amit Kapila <amit(dot)kapila(at)huawei(dot)com> wrote:
> > On Wednesday, January 09, 2013 4:52 PM 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?
> >
> > I have tried to dig why this gap is coming. I have observed that
> there is
> > very less change in normal path.
> > I wanted to give it some more time to exactly find if something can
> be done
> > to avoid performance dip in normal execution.
> >
> > Right now I am busy in certain other work. But definitely in coming
> week or
> > so, I shall spare time to work on it again.
>
> Perhaps. Not every idea produces useful outcomes. Even after your
> excellent research, it appears we haven't made this work yet. It's a
> shame. Should we invest more time? It's considered rude to advise
> others how to spend their time, but let me say this: we simply don't
> have enough time to do everything and we need to be selective,
> prioritising our time on to the things that look to give the best
> benefit.

I think we can reject this patch.

With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-01-10 09:31:04 Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
Previous Message Amit Kapila 2013-01-10 09:18:05 Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL