Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance tweak

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>
Cc: <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance tweak
Date: 2005-10-21 15:43:05
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE6C7AF0@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > This patch improves the win32 CHECK_FOR_INTERRUPTS() performance by
> > testing if any unblocked signals are queued before check
> > pgwin32_signal_event. This avoids an unnecessary system call.
>
> http://archives.postgresql.org/pgsql-patches/2005-10/msg00191.php
>
> This looks to me like a pretty important performance tweak
> for Windows.
> Can any of the people who worked on the Windows signal
> implementation look it over and confirm it's OK?

I think it looks good. (Haven't tested it yet, but from reading it.)

It seems it's safe to skip the interlocking that we do. If we miss one
signal for some reason, we will find it on the next hit to
CHECK_FOR_INTERRUPTS(). And if we get an "extra hit", we still
re-examine the stuff when we're locked, so it shouldn't be a big
problem.

Do you have any numbers on how much performance increases with it? I
agree that it looks like it could be a significant help in some cases,
but it'd be great to have numbers...

I'm a little bit concerned about doing it this late in beta, but it does
look safe to me. When it's that late, it'd be good to have one more
person review it though :)

//Magnus

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-10-21 16:55:17 Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance tweak
Previous Message Tom Lane 2005-10-21 15:29:20 Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance tweak