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? Thank you and sorry for the plethora of questions, but I know few about the inner parts of postgres:) lefteris On Thu, Jan 7, 2010 at 3:05 PM, Jochen Erwied <jochen@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > Thursday, January 7, 2010, 2:47:36 PM you wrote: > >> so I understand from all of you that you don't consider the use of 25k >> for sorting to be the cause of the slowdown? Probably I am missing > > Maybe you are reading the plan wrong: > > - the sort needs only 25kB of memory, and finishes in sub-second time, > mainly because the sort only sorts the already summarized data, and not > the whole table > - the sequential scan takes 346 seconds, and thus is the major factor in > time to finish! > > So the total query time is 371 seconds, of which 346 are required to > completely scan the table once. > > -- > Jochen Erwied | home: jochen@xxxxxxxxx +49-208-38800-18, FAX: -19 > Sauerbruchstr. 17 | work: joe@xxxxxxxxxxxxxxx +49-2151-7294-24, FAX: -50 > D-45470 Muelheim | mobile: jochen.erwied@xxxxxxxxxxx +49-173-5404164 > > -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
