| From: | Marti Raudsepp <marti(at)juffo(dot)org> |
|---|---|
| To: | Florian Weimer <fweimer(at)redhat(dot)com> |
| Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: 9.3.2 server creates hundreds of thousands of temporary files |
| Date: | 2014-01-22 19:02:28 |
| Message-ID: | CABRT9RCfDhvfmh5n9j-wLwKMk8S5wie=f=MckX0uLGwjqDRoOQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Wed, Jan 22, 2014 at 6:59 PM, Florian Weimer <fweimer(at)redhat(dot)com> wrote:
> This happens with postgresql-server-9.3.2-2.fc20.x86_64.
>
> I track this down to a lower-than-usual setting of work_mem, to 1MB, after
> the upgrade to 9.3.
>
> With work_mem set to 8MB, the query completes in a reasonable time frame,
> with just a few thousand temporary files. EXPLAIN ANALYZE gives these
> numbers:
Were the settings different on old and new PostgreSQL versions?
Do you have a query plan with the old version?
Are the join columns indexed on both sides?
Usually the planner prefers nested loops and merge joins with low
work_mem, if the join columns are indexed. Increasing
effective_cache_size and reducing random_page_cost to match your
hardware may lead the planner to make better choices.
Regards,
Marti
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Susan Cassidy | 2014-01-22 19:07:24 | Re: CREATE EXTENSION does not seem to work in 9.2 |
| Previous Message | joocom | 2014-01-22 18:21:42 | Re: upsert functionality |