Re: Idea to enhance pgbench by more modes to generate data (multi-TXNs, UNNEST, COPY BINARY)
| От | Boris Mironov |
|---|---|
| Тема | Re: Idea to enhance pgbench by more modes to generate data (multi-TXNs, UNNEST, COPY BINARY) |
| Дата | |
| Msg-id | DS0PR08MB956560D79EA051E98688F78088CAA@DS0PR08MB9565.namprd08.prod.outlook.com обсуждение исходный текст |
| Ответ на | Idea to enhance pgbench by more modes to generate data (multi-TXNs, UNNEST, COPY BINARY) (Boris Mironov <boris_mironov@outlook.com>) |
| Список | pgsql-hackers |
Hi Ashutosh,
> If there is one method that is better than all others, community will
> be more willing to accept implementation of that one method than
> multiple implementations so as to reduce maintenance burden.
Ok then. I'll leave "COPY FROM STDIN BINARY" implementation out of 3 only.
> multiple implementations so as to reduce maintenance burden.
Ok then. I'll leave "COPY FROM STDIN BINARY" implementation out of 3 only.
Would you prefer to replace original COPY FROM STDIN TEXT by this
code or add it as new "init-step" (e.g., with code "c")?
I also have noted that current code doesn't prevent pgbench parameter
like "--init-steps=dtgG". It allows to run data generation step twice.
Each of these "g" and "G" will present own timing in status line. Is this
an oversight or intentional?
> The code in the patch does not have enough comments. It's hard to
> understand the methods just from the code. Each of the generateData*
> functions could use a prologue explaining the data generation method
> it uses.
To add comments is not a problem at all. So far, it was just "code for myself"
> The code in the patch does not have enough comments. It's hard to
> understand the methods just from the code. Each of the generateData*
> functions could use a prologue explaining the data generation method
> it uses.
To add comments is not a problem at all. So far, it was just "code for myself"
and I was checking if there is any interest in community to include it.
>> I'm sure that much more testing is required to run this code under different
>> conditions and hardware to get a better picture. So far it looks very promising.
> Sure.
> Sure.
Cheers,
Boris
В списке pgsql-hackers по дате отправления: