Re: [Fwd: MySQL Benchmark page - Problem with vacuum() in PostgreSQL]
От | Michael Widenius |
---|---|
Тема | Re: [Fwd: MySQL Benchmark page - Problem with vacuum() in PostgreSQL] |
Дата | |
Msg-id | 15226.18645.421801.366971@narttu.mysql.fi обсуждение исходный текст |
Ответ на | Re: [Fwd: MySQL Benchmark page - Problem with vacuum() in PostgreSQL] (Jan Wieck <JanWieck@Yahoo.com>) |
Список | pgsql-general |
Hi! >>>>> "Jan" == Jan Wieck <JanWieck@yahoo.com> writes: Jan> Michael Widenius wrote: >> [...] >> >> Some things that I know we have missed in the single user >> benchmark are: >> - Sub select (all different forms of sub select, with a comparison >> to normal selects for those select that can be >> changed to normal selects) >> - Foreign keys (which should contain a comparison with multi-table-delete) >> - Transactions >> - Rollback >> >> With comparison I mean that there should be at least one test that >> makes it easy for the user to see which construct is better for >> this database. Jan> Can we clearify that point a little? Does it mean to define a Jan> foreign key constraint in databases that support it and just Jan> check for the error, but do all the appropriate locking and Jan> existence checks for all operations (UPDATE/DELETE PK, Jan> INSERT/UPDATE FK) on the client side for databases that don't Jan> support it? Jan> Well, especially because of the "appropriate locking", it'd Jan> make much more sense to do it all in concurrent multiuser ... Jan> :-) The plan is to (in the long run) have a test that shows ALL speed affects of foreign keys. This includes at least: - Checking the constraint - Time for forced rollback when a constraint fails - Time of cascaded deletes This above should of course be done both single and multi user. Regards, Monty
В списке pgsql-general по дате отправления: