From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgbench: Skipping the creating primary keys after initialization |
Date: | 2017-08-03 18:24:58 |
Message-ID: | alpine.DEB.2.20.1708031820090.16606@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> For the CREATE stuff, the script language is SQL, the command to use it is
>> "psql"...
>
>> The real and hard part is to fill tables with meaningful pseudo-random
>> test data which do not violate constraints for any non trivial schema
>> involving foreign keys and various unique constraints.
>
>> The solution for this is SQL for trivial cases, think of:
>> "INSERT INTO Foo() SELECT ... FROM generate_series(...);"
>
> Yeah. I was also thinking that complicated data-generation requirements
> could be handled with plpgsql DO blocks, avoiding the need for hard-wired
> code inside pgbench.
I do not thing that it is really be needed for what pgbench does, though.
See attached attempt, including a no_foreign_keys option.
The only tricky thing is to have the elapsed/remaining advancement report
on stdout, maybe with some PL/pgSQL.
Timings are very similar compared to "pgbench -i".
--
Fabien.
Attachment | Content-Type | Size |
---|---|---|
pgbench_init.sql | application/x-sql | 3.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-08-03 18:29:23 | Re: A bug in mapping attributes in ATExecAttachPartition() |
Previous Message | Andres Freund | 2017-08-03 18:14:01 | Re: Tightly packing expressions |