Re: Simulating Clog Contention

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