Thread: Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance

> And the patch that was applied gives the same result.
>
> What is more, I am not seeing the reported speedup - in fact
> I am seeing no speedup worth mentioning.
>
> This is on XP-Pro, with default postgres settings. The test
> sets were somewhat larger than thos Magnus used - basically
> TPC-H lineitems and orders tables (6m and 1.5m rows respectively).

First, that was Merlin and not me :-)

Second, it didn't really show any improvement for him either in his
normal test. But when he re-ran it with just the count(*) test it showed
improvement. Did you run a count(*) test or some other test?

//Magnus

Magnus Hagander wrote:

>>And the patch that was applied gives the same result.
>>
>>What is more, I am not seeing the reported speedup - in fact 
>>I am seeing no speedup worth mentioning.
>>
>>This is on XP-Pro, with default postgres settings. The test 
>>sets were somewhat larger than thos Magnus used - basically 
>>TPC-H lineitems and orders tables (6m and 1.5m rows respectively).
>>    
>>
>
>First, that was Merlin and not me :-)
>  
>

My apologies to both of you. Or to at least one of you, anyway. :-)

>Second, it didn't really show any improvement for him either in his
>normal test. But when he re-ran it with just the count(*) test it showed
>improvement. Did you run a count(*) test or some other test?
>
>  
>


The tests were

select count(*) from lineitems;
select count(*) from orders;

The table definitions are:



CREATE TABLE orders ( o_orderkey       INTEGER NOT NULL, o_custkey        INTEGER NOT NULL, o_orderstatus    CHAR(1)
NOTNULL, o_totalprice     DECIMAL(15,2) NOT NULL, o_orderdate      DATE NOT NULL, o_orderpriority  CHAR(15) NOT NULL,
--R o_clerk          CHAR(15) NOT NULL,  -- R o_shippriority   INTEGER NOT NULL, o_comment        VARCHAR(79) NOT NULL
 
);

CREATE TABLE lineitem ( l_orderkey    INTEGER NOT NULL, l_partkey     INTEGER NOT NULL, l_suppkey     INTEGER NOT NULL,
l_linenumber INTEGER NOT NULL, l_quantity    DECIMAL(15,2) NOT NULL, l_extendedprice  DECIMAL(15,2) NOT NULL,
l_discount   DECIMAL(15,2) NOT NULL, l_tax         DECIMAL(15,2) NOT NULL, l_returnflag  CHAR(1) NOT NULL, l_linestatus
CHAR(1) NOT NULL, l_shipdate    DATE NOT NULL, l_commitdate  DATE NOT NULL, l_receiptdate DATE NOT NULL, l_shipinstruct
CHAR(25)NOT NULL,  -- R l_shipmode     CHAR(10) NOT NULL,  -- R l_comment      VARCHAR(44) NOT NULL
 
);

I could make the whole dataset available, but tarred and zipped it's 
about 300Mb. The reason I used this dataset was that I wanted to see a 
test that took many seconds, and Merlin's did not - I wanted to see how 
any performance gain scaled.

But it looks to me like we need to leave this for 8.2 now anyway, unless 
someone can quickly get to the bottom of why it's hanging.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> I could make the whole dataset available, but tarred and zipped it's 
> about 300Mb. The reason I used this dataset was that I wanted to see a 
> test that took many seconds, and Merlin's did not - I wanted to see how 
> any performance gain scaled.

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.
        regards, tom lane

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>  
>
>>I could make the whole dataset available, but tarred and zipped it's 
>>about 300Mb. The reason I used this dataset was that I wanted to see a 
>>test that took many seconds, and Merlin's did not - I wanted to see how 
>>any performance gain scaled.
>>    
>>
>
>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.

cheers

andrew

Andrew Dunstan <andrew@dunslane.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