| От | devik@cdi.cz |
|---|---|
| Тема | Re: pgsql is 75 times faster with my new index scan |
| Дата | |
| Msg-id | 39D08D55.B57416F9@cdi.cz обсуждение |
| Ответ на | pgsql is 75 times faster with my new index scan (devik@cdi.cz) |
| Список | pgsql-hackers |
> That would be great, or alternatively, an attribute on the index? yes attribute would be nice. > > Dec RDB offers this kind of feature, and it suffers from deadlocking > problems because of index node vs. row locking as well as high lock > contention when updating indexed data, so it's not just the cost of doing > the updates. I definitely thinks it's a good feature to implement, if where is the reason of contention/ddlock ? We (or you?) only need to update index tuple's header data (like TX min/max) and key is untouched. So that all index scans should be able to go without disturbing. Index page should be locked in memory only for few ticks during actual memcpy to page. BTW: IMHO when WAL become functional, need we still multi versioned tuples in heap ? Why don't just version tuples on WAL log and add them during scans ? devik
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера