> >> What about the index size? How much space do they occupy? Analyze the >> table and do this > > > Of course space is different. That's not the point. The point is: I'm > willing > to pay the price for another HD, if that helps with performance. But it > doesn't. > >> >> The minimal performance difference is probably caused by the fact that >> we're dealing with int4 column (and you've used just 100000 rows, i.e. >> about 0.5MB of data) so the index is going to be tiny anyway. > > I've used 10M rows, not 100000. OK, I've misread the query - still, it's just 50MB of data. >> Let's try to do that with varchar(32) column, just do something like >> this > > > Did it with 5M rows. Still no difference. Hm, so the page splits probably are not that expensive to affect this. I wonder whether this would be true with multiple processes inserting data into the index concurrently. I guess the process needs to obtain a lock to do the page split, and that might make them much more expensive due to contention. But maybe I'm completely wrong - I really am not that familiar with btree internals yet and didn't have to investigate this. Anyway in your case (insert only, single process) I'd probably go with the default value (fillfactor=90). regards Tomas -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
