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