| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
| 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 14:18:59 |
| Message-ID: | 6835.1501769939@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
> As for a more generic solution, the easy part are the "CREATE" stuff and
> the transaction script stuff (existing pgbench scripts).
> 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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joe Conway | 2017-08-03 14:20:44 | Re: Macros bundling RELKIND_* conditions |
| Previous Message | Rod Taylor | 2017-08-03 14:13:30 | Re: Row Level Security Documentation |