Skip site navigation (1) Skip section navigation (2)

Re: testing HS/SR - 1 vs 2 performance

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Erik Rijkers <er(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: testing HS/SR - 1 vs 2 performance
Date: 2010-04-16 09:10:01
Message-ID: 1271409001.8305.7773.camel@ebony (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, 2010-04-16 at 11:29 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Tue, 2010-04-13 at 21:09 +0300, Heikki Linnakangas wrote:
> >> A quick fix would be to check if there's any entries in the hash table
> >> before scanning it. That would eliminate the overhead when there's no
> >> in-progress transactions in the master. But as soon as there's even one,
> >> the overhead comes back.
> > 
> > Any fix should be fairly quick because of the way its modularised - with
> > something like this in mind.
> > 
> > I'll try a circular buffer implementation, with fastpath.
> I started experimenting with a sorted array based implementation on
> Tuesday but got carried away with other stuff. I now got back to that
> and cleaned it up.
> How does the attached patch look like? It's probably similar to what you
> had in mind.

It looks like a second version of what I'm working on and about to
publish. I'll take that as a compliment!

My patch is attached here also, for discussion.

The two patches look same in their main parts, though I have quite a few
extra tweaks in there, which you can read about in comments. One tweak I
don't have is the use of the presence array that allows a sensible
bsearch, so I'll to alter my patch to use that idea but keep the rest of
my code.

 Simon Riggs 

Attachment: circular_knownassigned.patch
Description: text/x-patch (30.1 KB)

In response to


pgsql-hackers by date

Next:From: Oleg BartunovDate: 2010-04-16 09:25:46
Subject: Re: Very ineffective plan with merge join
Previous:From: Heikki LinnakangasDate: 2010-04-16 09:06:23
Subject: Re: Remaining Streaming Replication Open Items

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group