On Mon, 8 Apr 2019 at 02:59, Tom Lane <t...@sss.pgh.pa.us> wrote: > > David Rowley <david.row...@2ndquadrant.com> writes: > > hash_get_num_entries() looks cheap enough to me. Can you explain why > > you think that's too expensive? > > What I objected to cost-wise was counting the number of lock > acquisitions/releases, which seems entirely beside the point. > > We *should* be using hash_get_num_entries(), but only to verify > that the table is empty before resetting it. The additional bit > that is needed is to see whether the number of buckets is large > enough to justify calling the table bloated.
The reason I thought it was a good idea to track some history there was to stop the lock table constantly being shrunk back to the default size every time a simple single table query was executed. For example, a workload repeatably doing: SELECT * FROM table_with_lots_of_partitions; SELECT * FROM non_partitioned_table; I was worried that obtaining locks on the partitioned table would become a little slower because it would have to expand the hash table each time the query is executed. > > As cheap as possible sounds good, but I'm confused at why you think > > the table will always be empty at the end of transaction. > > It's conceivable that it won't be, which is why we need a test. > I'm simply arguing that if it is not, we can just postpone de-bloating > till it is. Session-level locks are so rarely used that there's no > need to sweat about that case. That seems fair. It would certainly simplify the patch. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
