Re: scheduler in core

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Lucas <lucas75(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: scheduler in core
Date: 2010-02-21 13:46:10
Message-ID: 4B813922.8050400@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule wrote:
>> This reasoning just doesn't fly in the PostgreSQL world. PostgreSQL is
>> designed to be extensible, not a monolithic product. We're not going to
>> change that because some companies have insane corporate policies. The
>> answer, as Jefferson said in another context, is to "inform their
>> ignorance."
>>
>> That isn't to say that there isn't a case for an in core scheduler, but this
>> at least isn't a good reason for it.
>>
>
> What I remember - this is exactly same discus like was about
> replication thre years ago
>
> fiirst strategy - we doesn't need it in core
> next we was last with replacation
>
>

That's a pretty poor analogy IMNSHO. There are very good technical
reasons to have replication in the core. That is much less clear for a
scheduler. But in any case, I didn't say that we shouldn't have a
scheduler. I specifically said there might be a case for it - read the
first clause of my last sentence. What I said was that the reason given,
namely that Corporations didn't want to use add-on modules, was not a
good reason.

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-02-21 14:23:11 Re: Plans for 9.1, Grouping Sets, disabling multiqueries, contrib module for string, plpgpsm, preload dictionaries
Previous Message Greg Stark 2010-02-21 12:57:13 Re: parallelizing subplan execution (was: explain and PARAM_EXEC)