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

Re: Simulating Clog Contention

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Simulating Clog Contention
Date: 2012-01-19 17:47:10
Message-ID: CA+TgmoZJU3rgz9tjM2fYuvAna7Xe_kabECv6Ym4z05bsDP=XCw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Jan 19, 2012 at 11:46 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Thu, Jan 19, 2012 at 4:12 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Thu, Jan 19, 2012 at 10:55 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>>> Also, I don't think the behavior described here should be joined at
>>>> the hip to --inserts:
>>>>
>>>> +        * We do this after a load by COPY, but before a load via INSERT
>>>> +        *
>>>> +        * This is done deliberately to ensure that no heap or index hints are
>>>> +        * set before we start running the benchmark. This emulates the case
>>>> +        * where data has arrived row at a time by INSERT, rather than being
>>>> +        * bulkloaded prior to update.
>>>>
>>>> I think that's also a useful behavior, but if we're going to have it,
>>>> we should have a separate option for it, like --create-indexes-early.
>>>> Otherwise, someone who wants to (for example) test only the impact of
>>>> doing inserts vs. COPY will get misleading answers.
>>>
>>> Creating indexes later would invalidate the test conditions I was
>>> trying to create, so that doesn't add a useful new initialisation
>>> mode. (Creating the indexes causes all of the hint bits to be set).
>>
>> Right, but the point is that to address Heikki's objection that this
>> is a special-purpose hack, we should try to make it general, so that
>> it can be used by other people for other things.
>
> This supports running hundreds of different tests because it creates a
> useful general starting condition. It's not a special purpose hack
> because its not a hack, nor is it special purpose.
>
> Yes, we could have an option to run with no indexes. Or we could have
> an option to run with 2 indexes as well. We could do all sorts of
> things. None of that is important, because there aren't any patches in
> the queue that need those tests and its too late to do it in this
> release. And if it really is important you can do it in the next
> release.
>
> If we have time to spend we should be spending it on running the patch
> to test the effectiveness of other patches in the queue, not on
> inventing new tests that have no relevance.

I feel I've adequate explained why it makes sense to me to separate
those options.  If you want, I'll do the work myself; it will take
less time than arguing about it.

On the other hand, if you wish to insist that we should only commit
this patch if --inserts makes multiple, unrelated, undocumented
changes to the initial test configurations, then I'll join Heikki in
voting against this.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Alex ShulginDate: 2012-01-19 17:59:35
Subject: Re: automating CF submissions (was xlog location arithmetic)
Previous:From: Marti RaudseppDate: 2012-01-19 17:46:13
Subject: Re: Simulating Clog Contention

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