Re: [PERFORMANCE] work_mem vs temp files issue

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, decibel <decibel(at)decibel(dot)org>, psql performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: [PERFORMANCE] work_mem vs temp files issue
Date: 2010-01-13 16:11:21
Message-ID: 603c8f071001130811g22387928g72262638532370e5@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, Jan 13, 2010 at 10:42 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I had an idea at one point of making explain show the planned and
>> actual # of batches for each hash join.  I believe that "actual # of
>> batches > 1" is isomorphic to "hash join went to disk".  The code is
>> actually pretty easy; the hard part is figuring out what to do about
>> the UI.  The choices seem to be:
>
>> 1. Create a new EXPLAIN option just for this - what would we call it?
>> 2. Think of some more, similar things and come up with a new EXPLAIN
>> option covering all of them - what else would go along with?
>> 3. Sandwhich it into an existing EXPLAIN option, most likely VERBOSE.
>> 4. Display it by default.
>
> Treat it the same as the Sort-node actual usage information.  We did not
> add a special option when we added that.

Well, what about when we're just doing EXPLAIN, not EXPLAIN ANALYZE?
It'll add another line to the output for the expected number of
batches.

...Robert

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Jaime Casanova 2010-01-13 16:14:55 Re: [PERFORMANCE] work_mem vs temp files issue
Previous Message Eduardo Piombino 2010-01-13 15:53:59 Re: a heavy duty operation on an "unused" table kills my server