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
> 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.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Alex Shulgin||Date: 2012-01-19 17:59:35|
|Subject: Re: automating CF submissions (was xlog location arithmetic)|
|Previous:||From: Marti Raudsepp||Date: 2012-01-19 17:46:13|
|Subject: Re: Simulating Clog Contention|