Re: SSI performance

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: SSI performance
Дата
Msg-id 4D4C3340020000250003A41F@gw.wicourts.gov
обсуждение исходный текст
Ответ на SSI performance  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: SSI performance  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-hackers
I wrote: 
>> If this works, it would be a very minor change, which might
>> eliminate a lot of that overhead for many common cases.
With that change in place, I loaded actual data from one county for
our most heavily searched table and searched it on the most heavily
searched index.  I returned actual data rather than a count, from
3654 rows.  On a less trivial and more common query like this, the
overhead of SSI tends to be lost in the noise:
select "nameL", "nameF", "nameM", "suffix",      "countyNo", "caseNo", "sex" from "Party" where "searchName" like
'WILLIAMS,%'order by "countyNo", "caseNo";
 
repeatable read
Time: 51.150 ms
Time: 54.809 ms
Time: 53.495 ms
Time: 51.458 ms
Time: 82.656 ms
serializable
Time: 54.105 ms
Time: 52.765 ms
Time: 52.852 ms
Time: 69.449 ms
Time: 52.089 ms
Unfortunately for those who rely on count(*), it is about the worst
case possible for highlighting SSI predicate locking overhead.
-Kevin


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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Linux filesystem performance and checkpoint sorting
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: SSI performance