On Wed, Sep 27, 2017 at 5:52 PM, Tomasz Ostrowski <tometzky...@ato.waw.pl> wrote: > I feel that this would eliminate a large amount of potential gains from such > an index. This would be usable only when a sufficiently variable column > exists, in which case a simple hash index on the column wouldn't be much > worse.
If the index isn't very selective and any query will match many rows anyway, I think it will often be superior to use a BRIN index (but I might be wrong). Maybe you're worrying about something like a billion-row table where there are 3 columns that form a composite key: (1,1,1), (1,1,2), ..., (1,1000),(1,2,1),...,(1,1000,1000),(2,1,1),...,(1000,1000,1000). In that case, treating the leading column as most important will indeed be terrible, since we'll put all billion rows into 1000 buckets no matter how many bucket splits we do. That seems a little unusual, though. -- 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
