Hello everyone, > It should be noted that such workload does not really represents 'real life' > results, > as all contention goes into certain partitions (in case of hashtable) and > subtrees (in case of tree). > Next goal is to compare data structures on some kind of realistic benchmark > or just create > multiple databases inside cluster and run corresponding number of pgbench > instances. >
i am still working on the better way to allocate and recycle different parts of the tree (nodes, subtrees, etc), but would like to share latest results of the benchmarks. Here is a link to the google sheet: https://docs.google.com/spreadsheets/d/1VfVY0NUnPQYqgxMEXkpxhHvspbT9uZPRV9mflu8UhLQ/edit?usp=sharing (Excuse me for the link, it is convenient to accumulate and check results in the sheets.) Comparison is done with pg 11.3 (0616aed243). Each tpc-h query ran 12 times. Server restarts weren't performed between queries. Average is calculated on base of 10 launches, first 2 are skipped. Generally speaking, current shared tree performs worse than the hashtable in the majority of the TPC-H test queries, especially in the case of 4GB shared buffers. With a greater size of the buffer cache - 16GB the situation looks better, but there is still a 1-6% performance drop in most of the queries. I haven't yet profile any query, but suppose that there are a couple of places worth optimizing. It is interesting to note that results of pgbench tests have the same pattern as in 128MB and 1GB buffer cache size: hashtable performs slightly better on select-only workload, while tree has better tps throughput in tpcb-like.
