Robert Haas <robertmhaas@xxxxxxxxx> wrote: > But isn't 13.5 seconds awfully slow to scan 149557 rows? The sort > is sorting 23960kB. Dividing that by 149557 rows gives ~169 > bytes/per row You're right. I would expect 9 ms as per tuple as a worst case if it doesn't need to go to TOAST data. Caching, multiple rows per page, or adjacent pages should all tend to bring it down from there. How does it get to 90 ms per row with rows that narrow? Is the table perhaps horribly bloated? Jeremy, did you try my suggestion of using CLUSTER on the index which will tend to be more selective? -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
