On Tue, Feb 4, 2014 at 4:24 PM, Peter Geoghegan wrote:
> There is something you have not drawn explicit attention to that is
> very interesting. If we take REL9_3_STABLE tip to be representative
> (built with full -O2 optimization, no assertions just debugging
> symbols), setting max_connections t
On Wed, Feb 5, 2014 at 7:21 AM, Andres Freund wrote:
> All current x86 processors use 64. But even if it were bigger/smaller,
> they will be either 32, or 128. Neither benefits from touching more
> cachelines than necessary. E.g. in the 128 case, we could still touch
> two with the current code.
On 2014-02-05 16:14:01 +0100, Greg Stark wrote:
> I see a lot of confusion online over whether cache lines
> are 64 bytes, 128 bytes, or other length even just on Intel
> architectures, let alone others.
All current x86 processors use 64. But even if it were bigger/smaller,
they will be either 32,
On Wed, Feb 5, 2014 at 3:57 PM, Tom Lane wrote:
> Maybe, or maybe not, but I think it does say that we should be very wary
> of proposals to force data structure alignment without any testing of the
> consequences.
Sure. see for instance
http://igoro.com/archive/gallery-of-processor-cache-effect
On 2014-02-05 09:57:11 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-02-04 16:24:02 -0800, Peter Geoghegan wrote:
> >> I suspect that the scenario described in this article accounts for the
> >> quite noticeable effect reported: http://danluu.com/3c-conflict
>
> > I don't think that'
Andres Freund writes:
> On 2014-02-04 16:24:02 -0800, Peter Geoghegan wrote:
>> I suspect that the scenario described in this article accounts for the
>> quite noticeable effect reported: http://danluu.com/3c-conflict
> I don't think that's applicable here.
Maybe, or maybe not, but I think it do
On 2014-02-04 16:24:02 -0800, Peter Geoghegan wrote:
> On Mon, Feb 3, 2014 at 3:38 PM, Andres Freund wrote:
> >> > A quick hack (attached) making BufferDescriptor 64byte aligned indeed
> >> > restored performance across all max_connections settings. It's not
> >> > surprising that a misaligned buf
On Mon, Feb 3, 2014 at 3:38 PM, Andres Freund wrote:
>> > A quick hack (attached) making BufferDescriptor 64byte aligned indeed
>> > restored performance across all max_connections settings. It's not
>> > surprising that a misaligned buffer descriptor causes problems -
>> > there'll be plenty of f
On Tue, Feb 4, 2014 at 4:21 AM, Andres Freund wrote:
> Which imo means fixing this got more important...
I strongly agree.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-
On 2014-02-04 00:38:19 +0100, Andres Freund wrote:
> > > A quick hack (attached) making BufferDescriptor 64byte aligned indeed
> > > restored performance across all max_connections settings. It's not
> > > surprising that a misaligned buffer descriptor causes problems -
> > > there'll be plenty of
On 2014-02-03 15:17:13 -0800, Peter Geoghegan wrote:
> On Sun, Feb 2, 2014 at 7:13 AM, Andres Freund wrote:
> > Just as reference, we're talking about a performance degradation from
> > 475963.613865 tps to 197744.913556 in a pgbench -S -cj64 just by setting
> > max_connections to 90, from 91...
>
On Sun, Feb 2, 2014 at 7:13 AM, Andres Freund wrote:
> Just as reference, we're talking about a performance degradation from
> 475963.613865 tps to 197744.913556 in a pgbench -S -cj64 just by setting
> max_connections to 90, from 91...
That's pretty terrible.
> So, I looked into this, and I am f
12 matches
Mail list logo
