Re: WIP: 2nd-generation buffer ring patch
От | Heikki Linnakangas |
---|---|
Тема | Re: WIP: 2nd-generation buffer ring patch |
Дата | |
Msg-id | 465DC010.1030109@enterprisedb.com обсуждение исходный текст |
Ответ на | WIP: 2nd-generation buffer ring patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: WIP: 2nd-generation buffer ring patch
|
Список | 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 по дате отправления: