Skip site navigation (1) Skip section navigation (2)

Re: Admission Control

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: Admission Control
Date: 2010-06-26 15:03:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Jun 25, 2010 at 03:15:59PM -0400, Robert Haas wrote:
>  A
> refinement might be to try to consider an inferior plan that uses less
> memory when the system is tight on memory, rather than waiting.  But
> you'd have to be careful about that, because waiting might be better
> (it's worth waiting 15 s if it means the execution time will decrease
> by > 15 s).

I think you could go a long way by doing something much simpler. We
already generate multiple plans and compare costs, why not just include
memory usage as a cost? If you start doing accounting for memory across
the cluster you can assign a "cost" to memory. When there are only a
few processes running it's cheap and you get plans like now. But as the
total memory usage increases you increase the "cost" of memory and
there will be increased pressure to produce lower memory usage plans.

I think this is better than just cutting plans out at a certain
threshold since it would allow plans that *need* memory to work
efficiently will still be able to.

(It doesn't help in situations where you can't accurately predict
memory usage, like hash tables.)

Have a nice day,
Martijn van Oosterhout   <kleptog(at)svana(dot)org>
> Patriotism is when love of your own people comes first; nationalism,
> when hate for people other than your own comes first. 
>                                       - Charles de Gaulle

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-06-26 15:37:16
Subject: Re: Admission Control
Previous:From: Mark WongDate: 2010-06-26 02:47:34
Subject: Re: parallelizing subplan execution (was: explain and PARAM_EXEC)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group