Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Magnus Hagander <mha(at)sollentuna(dot)net>, Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org, Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>
Subject: Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
Date: 2005-10-22 18:05:22
Message-ID: 2616.1130004322@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> 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?

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2005-10-22 18:39:04 Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
Previous Message Andrew Dunstan 2005-10-22 17:58:30 Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance