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 16:12:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.  For example, if the
options are separated, you can use this to measure how much slower
--inserts vs. the regular way.  But if that also changes the way
indexes are created, then you can't.  Moreover, since the
documentation mentioned only one of those two changes and not the
other, you might reasonably think that you've conducted a valid test.
We could document that --inserts changes the behavior in multiple
ways, but then the switch will end up being a bit of a misnomer, so I
think it's better to have a separate switch for each behavior someone
might want.

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2012-01-19 16:15:27
Subject: Re: Inline Extension
Previous:From: Robert HaasDate: 2012-01-19 16:06:37
Subject: Re: [v9.2] sepgsql's DROP Permission checks

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