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@pgsql-performance.erwied.eu> 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@erwied.eu +49-208-38800-18, FAX: -19
> Sauerbruchstr. 17 | work: joe@mbs-software.de +49-2151-7294-24, FAX: -50
> D-45470 Muelheim | mobile: jochen.erwied@vodafone.de +49-173-5404164
>
>