On 09/07/10 05:10, Josh Berkus wrote:
> Simon, Mark,
>
>> Actually only 1 lock check per query, but certainly extra processing and
>> data structures to maintain the pool information... so, yes certainly
>> much more suitable for DW (AFAIK we never attempted to measure the
>> additional overhead for non DW workload).
>
> I recall testing it when the patch was submitted for 8.2., and the
> overhead was substantial in the worst case ... like 30% for an
> in-memory one-liner workload.
>
Interesting - quite high! However I recall you tested the initial
committed version, later additions dramatically reduced the overhead
(what is in the Bizgres repo *now* is the latest).
> I've been going over the greenplum docs and it looks like the attempt
> to ration work_mem was dropped. At this point, Greenplum 3.3 only
> rations by # of concurrent queries and total cost. I know that
> work_mem rationing was in the original plans; what made that unworkable?
>
That certainly was my understanding too. I left Greenplum about the time
this was being discussed, and I think the other staff member involved
with the design left soon afterwards as well, which might have been a
factor!
> My argument in general is that in the general case ... where you can't
> count on a majority of long-running queries ... any kind of admission
> control or resource management is a hard problem (if it weren't,
> Oracle would have had it before 11). I think that we'll need to
> tackle it, but I don't expect the first patches we make to be even
> remotely usable. It's definitely not an SOC project.
>
> I should write more about this.
>
+1
Cheers
Mark