Re: WIP: 2nd-generation buffer ring patch - Mailing list pgsql-patches

From Heikki Linnakangas
Subject Re: WIP: 2nd-generation buffer ring patch
Date
Msg-id 465DC010.1030109@enterprisedb.com
Whole thread Raw
In response to WIP: 2nd-generation buffer ring patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: WIP: 2nd-generation buffer ring patch
List pgsql-patches
Tom Lane wrote:
> Updated version of Heikki's buffer ring patch, as per my comments here:
> http://archives.postgresql.org/pgsql-patches/2007-05/msg00449.php
>
> The COPY IN part of the patch is not there, pending resolution of
> whether we think it adds enough value to be worth uglifying
> heap_insert's API for.

I ran a series of tests, and it looks like it's not worth it.

The test case I used was DBT-2, with a big COPY running in the
background. That's the same method I used for SELECTs, just replaced the
SELECT COUNT(*) with a COPY FROM. The table I copied to was truncated
between COPYs, and had no indexes.

The results are inconclusive, because the results seem to be quite
inconsistent. With 100 warehouses, and no patch, I'm getting average
new-order response times between 1-3 seconds over 5 test runs. The
results with the patch are in the same range. Runs with 90 and 120
warehouses also varied greatly.

With the SELECTs, the patch made the big selects to finish quicker, in
addition to slightly reducing the impact on other queries. For COPY,
that benefit was not there either, and again there was a lot more
variance in how long time the COPYs took.

If there's a benefit for COPY from this patch, it's not clear enough to
spend effort on. The main problem with COPY seems to be that it causes a
very unpredictable impact on other queries. I can post the results if
someone wants to look at them, but I couldn't see any clear pattern in them.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [DOCS] OS/X startup scripts
Next
From: Heikki Linnakangas
Date:
Subject: Re: Seq scans status update