On Aug 19, 2012, at 2:37 PM, Jeff Davis <pg...@j-davis.com> wrote: > On Tue, 2012-07-10 at 00:09 -0700, Steven Schlansker wrote: >> I understand that the current wisdom is "don't use hash indices", but >> (unfortunately?) I have benchmarks that >> show that our particular application is faster by quite a bit when a >> hash index is available. > > Can you publish the results somewhere? It might provoke some interest.
I might be able to spend some time looking at making this public, but the general parameters are: 122M rows, lookup key is a UUID type. Lookups are ~1000 random keys at a time (as in, a giant SELECT * FROM table WHERE key IN (?,?,?,?,…) > >> I assume that fixing the hash index logging issue hasn't been a >> priority due to low interest / technical limitations, but I'm curious >> for a stopgap measure -- can we somehow configure Postgres to ignore >> hash indices on a replica, using other b-tree indices or even a >> sequential scan? I know I can do this on a per-connection basis by >> disabling various index lookup methods, but it'd be nice if it just >> ignored invalid indices on its own. > > This might work for you: > > http://sigaev.ru/git/gitweb.cgi?p=plantuner.git;a=blob;hb=HEAD;f=README.plantuner Thanks for the link; that looks interesting. It is a bit unfortunate that I would have to find and exclude indices manually, but very doable... -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
