> > 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
