From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
Subject: | Re: Avoiding repeated snapshot computation |
Date: | 2011-11-26 22:49:19 |
Message-ID: | 201111262349.20067.andres@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Saturday, November 26, 2011 11:39:23 PM Robert Haas wrote:
> On Sat, Nov 26, 2011 at 5:28 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On Saturday, November 26, 2011 09:52:17 PM Tom Lane wrote:
> >> I'd just as soon keep the fields in a logical order.
> >
> > Btw, I don't think the new order is necessarily worse than the old one.
>
> You forget to attach the benchmark results.
>
> My impression is that cache lines on modern hardware are 64 or 128
> *bytes*, in which case this wouldn't matter a bit.
All current x86 cpus use 64bytes. The 2nd 128bit reference was a typo. Sorry
for that.
And why is 72=>56 *bytes* (I even got that one right) not relevant for 64byte
cachelines?
And yea. I didn't add benchmark results. I don't think I *have* to do that
when making suggestions to somebody trying to improve something specific. I
also currently don't have hardware where I can sensibly run at a high enough
concurrency to see that GetSnapshotData takes ~40% of runtime.
Additional cacheline references around synchronized access can hurt to my
knowledge...
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2011-11-26 23:51:06 | Re: Avoiding repeated snapshot computation |
Previous Message | Robert Haas | 2011-11-26 22:39:23 | Re: Avoiding repeated snapshot computation |