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 15:55:10
Message-ID: CA+U5nMKoSQJ+Z6FXhnSZ_0r8FO0rFeYHHDOKWtj4tdvczAY+jg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 19, 2012 at 3:41 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> I agree: I think this is useful.
>
> However, I think we should follow the precedent of some of the other
> somewhat-obscure options we've added recently and have only a long
> form option for this: --inserts.

Yep, no problem.

> 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).

So that's just adding unrelated requirements for additional tests.
Yes, there are lots of additional tests we could get this code to
perform but we don't need to burden this patch with responsibility for
adding them, especially not when the tests mentioned don't refer to
any related patches in this commit fest and could be done at any time.
Any such change is clearly very low priority at this time.

> Finally, it's occurred to me that it would be useful to make pgbench
> respect -n even in initialization mode, and the SGML doc changes imply
> that this patch does that somewhere or other, but maybe only when
> you're doing INSERTS and not when you're doing copy, which would be
> odd; and there's no sgml doc update for -n, and no command-line help
> change either.

I'll fix the docs.

--
 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 Robert Haas 2012-01-19 16:06:37 Re: [v9.2] sepgsql's DROP Permission checks
Previous Message Robert Haas 2012-01-19 15:52:36 Re: Publish checkpoint timing and sync files summary data to pg_stat_bgwriter