> > Tom Lane wrote:
> >> Well, you tried to "scale" into a domain where the performance is
> >> going to be disk-I/O-limited, so I'm not sure it proves anything.
>
> > Good point. I took a 5% random extract from the lineitems table and
> > saw the expected improvement.
>
> Sounds better. Certainly there are cases where
> CHECK_FOR_INTERRUPTS isn't going to be a meaningful drag on
> performance, but there are others where it will be.
>
> BTW, looking at the code some more, I am thinking that
> checking pgwin32_signal_event should be completely
> unnecessary in pgwin32_check_queued_signals; that is, if
> UNBLOCKED_SIGNAL_QUEUE() is nonzero we might as well just
> enter pgwin32_dispatch_queued_signals unconditionally. The
> only usefulness of calling WaitForSingleObjectEx is to allow
> any pending APCs to be dispatched. Are there any other APCs
> queued against the main thread besides the timer.c one?
Right, the check should be unnecessary. We need the event, because we
wait on it in the socket layer and in pgwin32_backend_usleep(). But as
long as the event is still reset in pgwin32_dispatch_queued_signals,
that should continue to work just as before.
There should be no other APCs. After we learned that we can't do socket
operations in APCs, we got rid of all other instances (signals code
initially used it a lot). (Plus, if there were other APCs, they won't
get called anyway for the same reason the timer APC wasn't called any
more..)
(Tried removing it in my code, and it still passes regression tests and
deadlock test, so it looks good. I kept the
pgwin32_check_queued_signals, but we could just as well get rid of that
one then, since it'll only contain a call to dispatch. I just didn't
want to have to do a complete rebuild after changing the macro..)
//Magnus