Re: pgbench --tuple-size option

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgbench --tuple-size option
Date: 2014-08-15 12:42:54
Message-ID: CAHGQGwGMdoUFzwyHrjCyPCpE6xE9dccokwBjNcrk1wxZcF+SWQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 15, 2014 at 8:36 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2014-08-15 13:33:20 +0200, Fabien COELHO wrote:
>> >it seems to make more sense to split -i into two. One to create the
>> >tables, and another to fill them. That'd allow to do manual stuff
>> >inbetween.
>>
>> Hmmm. This would mean much more changes than the pretty trivial patch I
>> submitted
>
> FWIW, I find that patch really ugly. Adding the filler's with in a
> printf, after the actual DDL declaration. Without so much as a
> comment. Brr.
>
>>: more options (2 parts init + compatibility with the previous
>> case), splitting the "init" function, having a dependency and new error
>> cases to check (you must have the table to fill them), some options apply to
>> first part while other apply to second part, which would lead in any case to
>> a signicantly more complicated documentation... a lot of trouble for my use
>> case to answer Josh pertinent comments, and to be able to test the "tuple
>> size" factor easily. Moreover, I would reject it myself as too much trouble
>> for a small benefit.
>
> Well, it's something more generic, because it allows you do do more...
>
>> Feel free to reject the patch if you do not want it. I think that its
>> cost/benefit is reasonable (one small option, small code changes, some
>> benefit for people who want to measure performance in various cases).
>
> I personally think this isn't worth the price. But I'm just one guy.

I also don't like this feature. The benefit of this option seems too small.
If we apply this, we might want to support other options, for example,
option to change the data type of each column, option to create new
index using "minmax", option to change the fillfactor of each table, ...etc.
There are countless such options, but I'm afraid that it's really hard to
support so many options.

Regards,

--
Fujii Masao

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-08-15 12:46:30 Re: ALTER TABLESPACE MOVE command tag tweak
Previous Message Fujii Masao 2014-08-15 12:28:27 Re: Support for N synchronous standby servers