From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jon Nelson <jnelson+pgsql@jamponi.net>
Cc: pgsql-performance@postgresql.org
Subject: Re: problems with set_config, work_mem, maintenance_work_mem, and sorting
Date: Tue, 28 Feb 2012 16:54:43 -0500
Message-ID: <27623.1330466083@sss.pgh.pa.us> (raw)
In-Reply-To: <CAKuK5J0+Rpt3rwQJLCrzgBj-ShJWhVjxSAPS8tJSLOYGB4QA=Q@mail.gmail.com>
References: <CAKuK5J22ZTaVrVSPUerPA2_Fe-+udtOFWxSoOjFi9r9=5gyZgw@mail.gmail.com>
<9466.1330457283@sss.pgh.pa.us>
<CAKuK5J2rHEM_GCoCTPyw3ajn3yvg3QFX6apSiYbvJULDt_TGyg@mail.gmail.com>
<10857.1330462314@sss.pgh.pa.us>
<CAKuK5J0+Rpt3rwQJLCrzgBj-ShJWhVjxSAPS8tJSLOYGB4QA=Q@mail.gmail.com>
Jon Nelson <jnelson+pgsql@jamponi.net> writes:
> On Tue, Feb 28, 2012 at 2:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hmph ... does seem a bit weird. Can you turn on log_statements and
>> identify which operations aren't using the session values?
> I had log_min_duration_statement = 1000.
That's not really going to prove much, as you won't be able to see any
commands that might be setting or resetting the work_mem parameters.
> ... which is the ORM library (SQLAlchemy) doing a reflection of the
> table(s) involved.
Oh, there's an ORM involved? I'll bet a nickel it's doing something
surprising, like not issuing your SET until much later than you thought.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, jnelson+pgsql@jamponi.net
Subject: Re: problems with set_config, work_mem, maintenance_work_mem, and sorting
In-Reply-To: <27623.1330466083@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox