From: | Clodoaldo <clodoaldo(dot)pinto(dot)neto(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>, "PostgreSQL - General ML" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: ATTN: Clodaldo was Performance problem. Could it be related to 8.3-beta4? |
Date: | 2008-01-20 11:29:16 |
Message-ID: | a595de7a0801200329g5bd19961xeb534e84c7043176@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
2008/1/20, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Clodoaldo <clodoaldo(dot)pinto(dot)neto(at)gmail(dot)com> writes:
> > 2008/1/16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> >> I don't know of any reason to think that insertion is slower in 8.3
> >> than it was in 8.2, and no one else has reported anything of the sort.
>
> > The old server reproduces the behavior of the new one.
>
> Okay, Clodoaldo kindly gave me access to his old server, and after
> nearly a full day of poking at it I think I've figured out what is going
> on.
Thank you very much for working on this. That server will still be
available for a while if you want to poke further.
> You can see from the query that it's inserting the same constant "data"
> value into every new row, and if I understand the context correctly this
> value will be higher than all prior entries in the "usuarios" table.
Yes, that is correct. That value is this:
nextval('datas_data_serial_seq'::regclass)
> From
> this we can see that 8.2 has a working set that is a relatively small
> part of the index at any instant, whereas 8.3 has the entire index as
> working set ... and it doesn't fit into RAM. Ergo, lots of disk seek
> delays.
...
> A possibly usable workaround for now is "set enable_hashagg = off"
> to force a GroupAggregate plan, which will deliver the values sorted
> by (data, usuario) rather than by their hash values. This helps both
> versions, bringing the runtime down to something like 250 seconds,
> because the index on usuario then has complete locality of access.
> Alternatively, doubling the server's RAM would probably make the problem
> go away (for awhile, until the index reaches 4GB).
I need to say that the new server has 4GB and suffers the same
symptoms. OTOH if the proposed solution works then I wonder if it
matters.
Will "enable_hashagg" be settable(*) per query or only at server start/reload?
Regards, Clodoaldo Pinto Neto
* I didn't find this world at the dictionary but also didn't find
another one to say it.
From | Date | Subject | |
---|---|---|---|
Next Message | Ivan Sergio Borgonovo | 2008-01-20 12:10:39 | planner and simple vs. complex statement was: example query for postgresql |
Previous Message | Martijn van Oosterhout | 2008-01-20 10:36:24 | Re: ATTN: Clodaldo was Performance problem. Could it be related to 8.3-beta4? |