From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: scheduler in core |
Date: | 2010-03-01 21:49:53 |
Message-ID: | 162867791003011349v1925eb78vcd7d15021ac6630f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2010/3/1 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Sat, Feb 20, 2010 at 4:41 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> IMNSHO, an 'in core' scheduler would be useful. however, I think
>> before you tackle a scheduler, we need proper stored procedures. Our
>> existing functions don't cut it because you can manage the transaction
>> state yourself.
>
> Did you mean that you "can't" manage the transaction state yourself?
>
> Has anyone given any thought to what would be required to relax this
> restriction? Is this totally impossible given our architecture, or
> just a lack of round tuits?
I thing so it is very hard restriction based on using and architecture
of our SPI interface. Our stored procedures are executed inside one
SELECT statement - it is reason for limit. There cannot be two or more
outer transactions. Different implementations has different place of
runtime - it is more near to top of pipeline.
Pavel
>
> See also: http://www.postgresql.org/docs/current/static/plpgsql-porting.html#PLPGSQL-PORTING-EXCEPTIONS
>
> ...Robert
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2010-03-01 22:32:01 | Re: Re: Hot Standby query cancellation and Streaming Replication integration |
Previous Message | Robert Haas | 2010-03-01 21:43:41 | Re: scheduler in core |