2009/6/23 DaNieL..! <daniele.pignedoli@xxxxxxxxx>: > 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
