Did you try pgbouncer yet?
--
dim
I've only been using the bare-bones Postgres setup. And you're right,
connection pooling would be a good substitute, so I'll look into setting
that up. Thanks Dimitri.
Pgpool-II has similar functionality too. See client_idle_limit
directive in the
I'm fooling around with pushing FOR UPDATE locking into a new plan node
type, and I just noticed a behavior that seems a bit bogus.
Historically we have dealt with FOR UPDATE in sub-selects by flattening
the sub-select if we could, because the alternative was to fail
altogether. For example,
Hi,
Tom Lane wrote:
It's an entirely trivial code change either way. I'm inclined to think
that we should prevent flattening, on the grounds of least astonishment.
Yeah, I also tend towards making FOR UPDATE an optimization fence
(that's how I understood the non-flattening approach). While it
Markus Wanner mar...@bluegap.ch writes:
BTW: how do other databases deal with this? Anything of relevance in the
SQL standards?
SQL99 treats FOR UPDATE as an attribute of DECLARE CURSOR, so there's
no way for it to appear in a sub-select per spec. (In general our
approach to FOR UPDATE is only
Folks,
I'd like to see about creating man pages for the following:
- libpq
- SPI
- the built-in functions
These being what I've clicked through way too many web links to find
information about. If there are other things that should have man
pages, please mention same.
How would that be
On Sun, Oct 11, 2009 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm fooling around with pushing FOR UPDATE locking into a new plan node
type, and I just noticed a behavior that seems a bit bogus.
Historically we have dealt with FOR UPDATE in sub-selects by flattening
the sub-select if we
David Fetter wrote:
Folks,
I'd like to see about creating man pages for the following:
- libpq
- SPI
- the built-in functions
That would be really helpful and convenient. I've often wanted libpq man pages.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via
Robert Haas robertmh...@gmail.com writes:
On Sun, Oct 11, 2009 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It's an entirely trivial code change either way. I'm inclined to think
that we should prevent flattening, on the grounds of least astonishment.
It seems like this is somewhat
On Fri, Oct 09, 2009 at 04:35:46PM -0500, Kevin Grittner wrote:
Peter Eisentraut pete...@gmx.net wrote:
I think the setting ought be called linestyle unicode (instead of
utf8), since the same setting would presumably work in case we ever
implement UTF-16 support on the client side.
David Fetter wrote:
Folks,
I'd like to see about creating man pages for the following:
- libpq
- SPI
- the built-in functions
These being what I've clicked through way too many web links to find
information about. If there are other things that should have man
pages, please mention
Alvaro Herrera alvhe...@commandprompt.com writes:
As for builtin functions, I think that's going to be a very hard sell.
Fresh out of the box, there are 2227 entries in pg_proc as of CVS HEAD.
I don't see making a man page for each one as being a useful activity
...
On Sun, Oct 11, 2009 at 09:18:20PM -0400, Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
As for builtin functions, I think that's going to be a very hard
sell.
Fresh out of the box, there are 2227 entries in pg_proc as of CVS
HEAD. I don't see making a man page for
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Please review the new revision, Thanks,
In general, I'm pretty happy with this revision. You still have a
number of places where you have comments about code which does not exist
any more. For example, the comments about the check being
13 matches
Mail list logo
