On Thu, Jan 19, 2012 at 11:46 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On Thu, Jan 19, 2012 at 4:12 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Thu, Jan 19, 2012 at 10:55 AM, Simon Riggs <si...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
