2009/6/23 DaNieL..! <daniele.pignedoli@gmail.com>:
> The `problem` is that i dont know if having so many indexes will raise
> problems as the data dimension grown.
> That seem to be not very efficient: http://explain.depesz.com/s/Q0m
Well, this is slow, because for some reason postgres decided to use
seq scan on contact e.
As for speed with many indices. Btree for varchar is going to be
slower, than - say for integer, or any other fixed length type.
This is due to nature of index. Having said that, if you expect a lot
of repetition, split it/normalize it.
Index performance also hurts, when you get a lot of variants of data
(worse case, all varchar rows are different, and don't share too many
leafs on index).
So it is always beneficial to have separate table, if data is
redundant - especially when it is text/varchar/bytea.
Also, index size grows pretty badly when you modify table's content a
lot in postgresql.
Rule of thumb, bigger the index in size, comparable to data size - the worse.
--
GJ
