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 по дате отправления:

Предыдущее
От: Jochem van Dieten
Дата:
Сообщение: Re: Calling stored procedures.
Следующее
От: Killian May
Дата:
Сообщение: Missing Sequence File