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
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 |