On Tue, Jul 26, 2016 at 8:43 PM, Andres Freund <and...@anarazel.de> wrote: > As previously mentioned, dynahash isn't particularly fast. In many cases > that doesn't particularly matter. But e.g. hash aggregation and bitmap > index scans are quite sensitive to hash performance. > > The biggest problems with dynahash (also discussed at [1]) are > > a) two level structure doubling the amount of indirect lookups > b) indirect function calls > c) using separate chaining based conflict resolution > d) being too general.
I am ... skeptical about open addressing. It's less unappealing for this application than in general because we don't actually need to delete anything, but that wouldn't be true for the catcache. All the same, I feel that we need to assess the risk that we're improving average-case performance while creating large regressions in other cases (i.e. where there is clustering). Do likely() and unlikely() actually buy us anything here? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
