From: | Uwe Bartels <uwe(dot)bartels(at)gmail(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: maintenance_work_mem + create index |
Date: | 2011-03-24 14:40:33 |
Message-ID: | AANLkTikQO+y2nWz4SjjUMKkGDCVFFL0Z_8bu9poUyk=9@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
OK. I didn't now that. Thanks for sharing that information.
Can anybody tell if we have this limitation on maintenance_work_mem as well?
Does anybody know of a solution out of that on Linux?
Or is there a dynamic way to put $PGDATA/base/pgsql_tmp into RAM without
blocking it completely like a ram disk?
Best Regards,
Uwe
On 24 March 2011 15:13, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Uwe,
>
> * Uwe Bartels (uwe(dot)bartels(at)gmail(dot)com) wrote:
> > So I checked this again and raised afterwards maintenance_work_mem step
> by
> > step up 64GB.
> > I logged in via psql, run the following statements
> > set maintenance_work_mem = '64GB';
>
> I believe maintenance_work_mem suffers from the same problem that
> work_mem has, specifically that PG still won't allocate more than
> 1GB of memory for any single operation.
>
> Thanks,
>
> Stephen
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk2LUW8ACgkQrzgMPqB3kigZMwCfUVL/5nSdK5xiV+/SjWB6BG9B
> Fm0An2V5Tald8PUYXc5VIuKL/C1WNYTp
> =MSxh
> -----END PGP SIGNATURE-----
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Shaun Thomas | 2011-03-24 15:14:01 | Re: maintenance_work_mem + create index |
Previous Message | Stephen Frost | 2011-03-24 14:13:03 | Re: maintenance_work_mem + create index |