Robert Haas wrote:
> Kevin Grittner wrote:
>> The second tier is implemented to run after a plan is chosen, and
>> may postpone execution of a query (or reduce the resources it is
>> allowed) if starting it at that time might overload available
>> resources.
>
> It seems like it might be helpf
Robert Haas wrote:
> It seems like it might be helpful, before tackling what you're
talking
> about here, to have some better tools for controlling resource
> utilization. Right now, the tools we have a pretty crude. You
can't
> even nice/ionice a certain backend without risking priority
inver
On Mon, Dec 28, 2009 at 3:33 PM, Kevin Grittner
wrote:
> They describe a two-tier approach, where the first tier is already
> effectively implemented in PostgreSQL with the max_connections and
> superuser_reserved_connections GUCs. The second tier is implemented
> to run after a plan is chosen, a
Dimitri Fontaine wrote:
> No, in session pooling you get the same backend connection for the
> entire pgbouncer connection, it's a 1-1 mapping.
Right -- so it doesn't allow more logical connections than that with
a limit to how many are active at any one time, *unless* the clients
cooperate by
Le 28 déc. 2009 à 23:56, Kevin Grittner a écrit :
>> http://preprepare.projects.postgresql.org/README.html
>
> I just reviewed the documentation for preprepare -- I can see a use
> case for that, but I really don't think it has a huge overlap with
> my point. The parsing and planning mentioned i
Dimitri Fontaine wrote:
> Le 28 déc. 2009 à 22:59, Kevin Grittner a écrit :
>> (3) With the ACP, the statements would be parsed and optimized
>> before queuing, so they would be "ready to execute" as soon as a
>> connection was freed.
>
> There's a pgfoundry project called preprepare, which ca
Le 28 déc. 2009 à 23:35, Kevin Grittner a écrit :
> So the application would need to open and close a pgbouncer
> connection for each database transaction in order to share the
> backend properly?
No, in session pooling you get the same backend connection for the entire
pgbouncer connection, it's
Dimitri Fontaine wrote:
> That's why there's both transaction and session pooling. The
> benefit of session pooling is to avoid forking backends, reusing
> them instead, and you still get the pooling control.
So the application would need to open and close a pgbouncer
connection for each datab
Le 28 déc. 2009 à 22:59, Kevin Grittner a écrit :
> With my current knowledge of pgbouncer I can't answer that
> definitively; but *if* pgbouncer, when configured for transaction
> pooling, can queue new transaction requests until a connection is
> free, then the differences would be:
It does that
Dimitri Fontaine wrote:
> Le 28 déc. 2009 à 21:33, Kevin Grittner a écrit :
>> We often see posts from people who have more active connections
>> than is efficient.
>
> How would your proposal better solve the problem than using
> pgbouncer?
With my current knowledge of pgbouncer I can't answer
Le 28 déc. 2009 à 22:46, Andres Freund a écrit :
>>
>> I'd be in favor of considering how to get pgbouncer into -core, and now
>> that we have Hot Standby maybe implement a mode in which as soon as a
>> "real" XID is needed, or maybe upon receiving start transaction read write
>> command, the conn
On Monday 28 December 2009 22:39:06 Dimitri Fontaine wrote:
> Hi,
>
> Le 28 déc. 2009 à 21:33, Kevin Grittner a écrit :
> > We often see posts from people who have more active connections than
> > is efficient.
>
> How would your proposal better solve the problem than using pgbouncer?
>
>
> I'd
Hi,
Le 28 déc. 2009 à 21:33, Kevin Grittner a écrit :
> We often see posts from people who have more active connections than
> is efficient.
How would your proposal better solve the problem than using pgbouncer?
I'd be in favor of considering how to get pgbouncer into -core, and now that we
ha
This paper has a brief but interesting discussion of Admission
Control in section 2.4:
Architecture of a Database System. (Joseph M. Hellerstein, Michael
Stonebraker and James Hamilton). Foundations and Trends in Databases
1(2).
http://db.cs.berkeley.edu/papers/fntdb07-architecture.pdf
They d
14 matches
Mail list logo
