Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization
От | Masahiko Sawada |
---|---|
Тема | Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization |
Дата | |
Msg-id | CAD21AoD6QxRU9Z7piyBJRjKJARC=Y1uxaZ9yNfi3D8zDfC4TBA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] pgbench: Skipping the creating primary keys afterinitialization (Fabien COELHO <coelho@cri.ensmp.fr>) |
Список | pgsql-hackers |
On Fri, Aug 4, 2017 at 3:24 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote: > >>> 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". > The generating data with plpgsql DO blocks means that we do the data-generation on sever side rather than on client side. I think it's preferable in a sense because could speed up initialization time by reducing the network traffic. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: