On Thu, Jul 11, 2019 at 8:09 AM Alexander Korotkov <a.korot...@postgrespro.ru> wrote: > BTW, I think deduplication could cause some small performance > degradation in some particular cases, because page-level locks became > more coarse grained once pages hold more tuples. However, this > doesn't seem like something we should much care about. Providing an > option to turn deduplication off looks enough for me.
There was an issue like this with my v12 work on nbtree, with the TPC-C indexes. They were always ~40% smaller, but there was a regression when TPC-C was used with a small number of warehouses, when the data could easily fit in memory (which is not allowed by the TPC-C spec, in effect). TPC-C is very write-heavy, which combined with everything else causes this problem. I wasn't doing anything too fancy there -- the regression seemed to happen simply because the index was smaller, not because of the overhead of doing page splits differently or anything like that (there were far fewer splits). I expect there to be some regression for workloads like this. I am willing to accept that provided it's not too noticeable, and doesn't have an impact on other workloads. I am optimistic about it. > Regarding bitmap indexes itself, I think our BRIN could provide them. > However, it would be useful to have opclass parameters to make them > tunable. I thought that we might implement them in nbtree myself. But we don't need to decide now. -- Peter Geoghegan
