Re: gprof SELECT COUNT(*) results

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas DCP SD
Тема Re: gprof SELECT COUNT(*) results
Дата
Msg-id E1539E0ED7043848906A8FF995BDA579A16447@m0143.s-mxs.net
обсуждение исходный текст
Ответ на gprof SELECT COUNT(*) results  (Qingqing Zhou <zhouqq@cs.toronto.edu>)
Список pgsql-hackers
> > OTOH DB2 and SQLServer take block level
> > read locks, so they can do this too, but at major loss of
concurrency
> > and threat of deadlock.

Note, that in the usual committed read isolation, they do not need to
read lock a row ! e.g. Informix only verifies, that it could lock the
row
(that there is no write lock). Only cursor stability leaves one read
lock
until the next fetch, serializable actually leaves all read locks,
and select for update an intent update lock.

Also they usually feed a buffer of rows to the client, so if the client
does a fetch it gets a row from the client side buffer. Only when the
buffer
is empty, they get more from the server.

I think the statement holds, that the optimization is pg specific,
and cannot be directly compared to other db's.

Andreas


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Qingqing Zhou"
Дата:
Сообщение: Re: ice-broker scan thread
Следующее
От: "Mario Weilguni"
Дата:
Сообщение: Re: Hashjoin startup strategy (was Re: Getting different number of results when using hashjoin on/off)