On Fri, Jun 28, 2013 at 2:46 AM, Heikki Linnakangas wrote:
> On 27.06.2013 17:30, Robert Haas wrote:
>
>> On Wed, Jun 26, 2013 at 5:49 PM, Jeff Janes wrote:
>>
>>> If we think the patch has a risk of introducing subtle errors, then it
>>>
>>> probably can't be justified based on the small perfor
On 27.06.2013 17:30, Robert Haas wrote:
On Wed, Jun 26, 2013 at 5:49 PM, Jeff Janes wrote:
If we think the patch has a risk of introducing subtle errors, then it
probably can't be justified based on the small performance gains you saw.
But if we think it has little risk, then I think it is jus
On Wed, Jun 26, 2013 at 5:49 PM, Jeff Janes wrote:
> On Tue, Jun 18, 2013 at 12:09 AM, Heikki Linnakangas
> wrote:
>> Jeff's patch seems to somewhat alleviate the huge fall in performance I'm
>> otherwise seeing without the nonlocked-test patch. With the nonlocked-test
>> patch, if you squint you
On 06/26/2013 02:49 PM, Jeff Janes wrote:
> I see in the commitfest app it is set to "Waiting on Author" (but I don't
> know who "maiku41" is).
Mike Blackwell, who's helping track patches for the CommitFest.
It's been our practice since the 9.3 cycle that patches which are still
under contentious
Jeff Janes escribió:
> I see in the commitfest app it is set to "Waiting on Author" (but I don't
> know who "maiku41" is).
Yeah, that guy is misterious. I'm guessing the Mike Blackwell person
Josh mentioned in his "week 1" report.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
Po
On Tue, Jun 18, 2013 at 12:09 AM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
>
> Jeff's patch seems to somewhat alleviate the huge fall in performance I'm
> otherwise seeing without the nonlocked-test patch. With the nonlocked-test
> patch, if you squint you can see a miniscule benefit.
On Tue, 18 Jun 2013 11:41:06 +0300
Heikki Linnakangas wrote:
> Oh, interesting. What kind of hardware are you running on? To be honest,
> I'm not sure what my test hardware is, it's managed by another team
> across the world, but /proc/cpuinfo says:
>
> model name: Intel(R) Xeon(R) CPU E5-
On 18.06.2013 10:52, David Gould wrote:
On Tue, 18 Jun 2013 10:09:55 +0300
Heikki Linnakangas wrote:
I repeated these pgbench tests I did earlier:
http://www.postgresql.org/message-id/5190e17b.9060...@vmware.com
I concluded in that thread that on this platform, the TAS_SPIN macro
really need
On Tue, 18 Jun 2013 10:09:55 +0300
Heikki Linnakangas wrote:
> On 02.04.2013 22:58, David Gould wrote:
> > I'll give the patch a try, I have a workload that is impacted by spinlocks
> > fairly heavily sometimes and this might help or at least give me more
> > information. Thanks!
>
> Did you ev
Hi David,
On 02.04.2013 22:58, David Gould wrote:
On Tue, 2 Apr 2013 09:01:36 -0700
Jeff Janes wrote:
Sorry. I triple checked that the patch was there, but it seems like if you
save a draft with an attachment, when you come back later to finish and
send it, the attachment may not be there an
On Tue, 2 Apr 2013 09:01:36 -0700
Jeff Janes wrote:
> Sorry. I triple checked that the patch was there, but it seems like if you
> save a draft with an attachment, when you come back later to finish and
> send it, the attachment may not be there anymore. The Gmail Offline teams
> still has a wa
On Monday, April 1, 2013, Tom Lane wrote:
> Jeff Janes writes:
> > The problem is that the state is maintained only to an integer number of
> > milliseconds starting at 1, so it can take a number of attempts for the
> > random increment to jump from 1 to 2, and then from 2 to 3.
>
> Hm ... fair p
On Tue, Apr 2, 2013 at 1:24 AM, Tom Lane wrote:
> Jeff Janes writes:
>> The problem is that the state is maintained only to an integer number of
>> milliseconds starting at 1, so it can take a number of attempts for the
>> random increment to jump from 1 to 2, and then from 2 to 3.
>
> Hm ... fai
Jeff Janes writes:
> The problem is that the state is maintained only to an integer number of
> milliseconds starting at 1, so it can take a number of attempts for the
> random increment to jump from 1 to 2, and then from 2 to 3.
Hm ... fair point, if you assume that the underlying OS has a sleep
While stracing a process that was contending for a spinlock, I noticed that
the sleep time would often have a longish sequence of 1 and 2 msec sleep
times, rather than the rapidly but randomly increasing sleep time intended.
(At first it looked like it was sleeping on a different attempt each time
15 matches
Mail list logo
