Lefteris escribió: > Yes, I am reading the plan wrong! I thought that each row from the > plan reported the total time for the operation but it actually reports > the starting and ending point. > > So we all agree that the problem is on the scans:) > > So the next question is why changing shared memory buffers will fix > that? i only have one session with one connection, do I have like many > reader workers or something? No amount of tinkering is going to change the fact that a seqscan is the fastest way to execute these queries. Even if you got it to be all in memory, it would still be much slower than the other systems which, I gather, are using columnar storage and thus are perfectly suited to this problem (unlike Postgres). The talk about "compression ratios" caught me by surprise until I realized it was columnar stuff. There's no way you can get such high ratios on a regular, row-oriented storage. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
