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>
> >> > 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
I think we can reject this patch.
In response to
pgsql-hackers by date
|Next:||From: Andres Freund||Date: 2013-01-10 09:31:04|
|Subject: Re: Re: [PATCH] unified frontend support for pg_malloc et
al and palloc/pfree mulation (was xlogreader-v4)|
|Previous:||From: Amit Kapila||Date: 2013-01-10 09:18:05|
|Subject: Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL|