Re: pgbench - allow to create partitioned tables
Fabien COELHO <coelho@cri.ensmp.fr>
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Asif Rehman <asifr.rehman@gmail.com>,
PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2019-09-21T07:48:31Z
Lists: pgsql-hackers
Attachments
- pgbench-init-partitioned-14.patch (text/x-diff) patch
Hello Amit, > Yes, this code is correct. I am not sure if you understood the point, > so let me try again. I am bothered about below code in the patch: > + /* only print partitioning information if some partitioning was detected */ > + if (partition_method != PART_NONE) > > This is the only place now where we check 'whether there are any > partitions' differently. I am suggesting to make this similar to > other checks (if (partitions > 0)). As I said somewhere up thread, you can have a partitioned table with zero partitions, and it works fine (yep! the update just does not do anything…) so partitions > 0 is not a good way to know whether there is a partitioned table when running a bench. It is a good way for initialization, though, because we are creating them. sh> pgbench -i --partitions=1 sh> psql -c 'DROP TABLE pgbench_accounts_1' sh> pgbench -T 10 ... transaction type: <builtin: TPC-B (sort of)> scaling factor: 1 partition method: hash partitions: 0 query mode: simple number of clients: 1 number of threads: 1 duration: 10 s number of transactions actually processed: 2314 latency average = 4.323 ms tps = 231.297122 (including connections establishing) tps = 231.549125 (excluding connections establishing) As postgres does not break, there is no good reason to forbid it. > [...] Sure, even in that case your older version of pgbench will be able > to detect by below code [...] "unexpected partition method: " [...]. Yes, that is what I was saying. > Hmm, you have just written what each part of the query is doing which I > think one can identify if we write some general comment as I have in the > patch to explain the overall intent. Even if we write what each part of > the statement is doing, the comment explaining overall intent is > required. There was some comments. > I personally don't like writing a comment for each sub-part of the query > as that makes reading the query difficult. See the patch sent by me in > my previous email. I did not notice there was an attachment. > I have done that in some of the cases in the patch attached by me in > my last email. Have you looked at those changes? Nope, as I was not expected one. > Try to make those changes in the next version unless you see something > wrong is written in comments. I incorporated most of them, although I made them terser, and fixed them when inaccurate. I did not buy moving the condition inside the fillfactor function. See attached v14. -- Fabien.
Commits
-
pgbench: add --partitions and --partition-method options.
- b1c1aa531823 13.0 landed