Skip site navigation (1) Skip section navigation (2)

Re: WIP: 2nd-generation buffer ring patch

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgreSQL(dot)org
Subject: Re: WIP: 2nd-generation buffer ring patch
Date: 2007-05-30 18:18:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Tom Lane wrote:
> Updated version of Heikki's buffer ring patch, as per my comments here:
> 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

In response to


pgsql-patches by date

Next:From: Heikki LinnakangasDate: 2007-05-30 18:27:46
Subject: Re: Seq scans status update
Previous:From: Bruce MomjianDate: 2007-05-30 18:10:54
Subject: Re: OS/X startup scripts

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group