Hello, Álvaro > So you were saying some posts upthread that the new hash tables would > "borrow" AN elements from the freelist then put AN elements back when > too many got unused. Is that idea embodied in this patch?
Right. It didn't satisfy "use all memory" requirement anyway. It's better to sacrifice a few TPS (according only to my benchmark which doesn't represent all possible use cases) than accidentally break someones system after upgrading to the next version of PostgreSQL. See example with pg_dump given by Robert Haas above. >> +/* Number of partitions of the shared buffer mapping hashtable */ >> +#define NUM_BUFFER_PARTITIONS NUM_LOCK_PARTITIONS >> + >> /* Number of partitions the shared predicate lock tables are divided >> into */ #define LOG2_NUM_PREDICATELOCK_PARTITIONS 4 >> #define NUM_PREDICATELOCK_PARTITIONS (1 << >> LOG2_NUM_PREDICATELOCK_PARTITIONS) > > I find this odd. Why is it a good idea to define the bufMapping > partitions like this? What's the explanation for the performance > numbers you saw? My mistake. I thought that last table was self-explanatory. We see that a single spinlock for accessing a freeList (current implementation) is obviously a bottleneck. Replacing it with say an array of spinlocks reduces lock contention and therefore gives more TPS (see first row). Also we can increase concurrency level even further by increasing number of lock partitions (see columns "no locks", "lwlock" and "spinlock array"). Previously it couldn't help us (see "master" column) because of a bottleneck. If you have any other questions regarding this patch please don't hesitate to ask. Best regards, Aleksander -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
