On Wed, Sep 21, 2011 at 8:08 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: >> How about almost every primary index creation? > > Nope. Swamped by everything else.
Really? I think it's pretty common for shops to be able to dedicate large amounts of RAM to building initial indexes on data loads or reindex operations. Enough that they can cache the entire table for the short time they're doing the index builds even if they're quite large. Witness the recent pleas to allow maintenance_work_mem on the order of tens of gigabytes. And it's also pretty common that shops can dedicate very large I/O bandwidth, in many cases enough to saturate the memory bandwidth, for doing these kinds of batch operations when they get large enough to need to do an external sort. There's still overhead of reading the pages, the tuples, finding the sort keys in the tuple, etc. But I think the actual qsort or heap operations in tapesort are pretty big portions of the work. This is pretty easy to measure. Just run oprofile or gprof and see what percentage of time for a big index build is spent in qsort. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers