Re: Simulating Clog Contention

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(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 16:46:02
Message-ID: CA+U5nMKiRKw6_a-zFY5+Won0QCPaKQVksx-rsB6WMTk6w5rbPA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2012-01-19 16:56:31 Re: Publish checkpoint timing and sync files summary data to pg_stat_bgwriter
Previous Message Tom Lane 2012-01-19 16:15:27 Re: Inline Extension