Re: Idea to enhance pgbench by more modes to generate data (multi-TXNs, UNNEST, COPY BINARY)
| От | Ashutosh Bapat |
|---|---|
| Тема | Re: Idea to enhance pgbench by more modes to generate data (multi-TXNs, UNNEST, COPY BINARY) |
| Дата | |
| Msg-id | CAExHW5vtdtd5QnFobxOhbVeh5jk3_61zYRxLqCXEZpO3jOeFDg@mail.gmail.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 Boris, On Wed, Nov 12, 2025 at 3:25 AM Boris Mironov <boris_mironov@outlook.com> wrote: > > Hello hackers, > > For some of my specific hardware tests I needed to generate big databases well beyond RAM size. Hence I turned to pgbenchtool and its default 2 modes for client- and server-side generation for TPC-B tests. When I use "scale" factor inrange of few thousands (eg, 3000 - 5000) data generation phase takes quite some time. I looked at it as opportunity toprove/disprove 2 hypothesises: > > will INSERT mode work faster if we commit once every "scale" and turn single INSERT into "for" loop with commits for 3tables in the end of each loop > will "INSERT .. SELECT FROM unnest" be faster than "INSERT .. SELECT FROM generate_series" > will BINARY mode work faster than TEXT even though we send much more data > and so on > > As a result of my experiments I produced significant patch for pgbench utility and though that it might be of interestnot just for me. Therefore I'm sending draft version of it in diff format for current development tree on GitHub.As of November 11, 2025 I can merge with main branch of the project on GitHub. > > Spoiler alert: "COPY FROM BINARY" is significantly faster than current "COPY FROM TEXT" > > Would be happy to polish it if there is interest to such change. Making pgbench data initialization faster at a higher scale is desirable and the community might be willing to accept such a change. Running very large benchmarks is becoming common these days. However, it's not clear what you are proposing and what's the performance improvement. Answering following question may help: Your patch implements all the above methods? Do all of them provide performance improvement? If each of them performs better under certain conditions, what are those conditions? Is there one method which performs better than all others, which is it and why not implement just that method? What performance numbers are we looking at? Can the methods which use batch commits, also run those batches in parallel? -- Best Wishes, Ashutosh Bapat
В списке pgsql-hackers по дате отправления: