On Mon, 2013-07-08 at 14:20 -0500, Jerry Sievers wrote:
Planning to pg_upgrade some large (3TB) clusters using hard link
method. Run time for the upgrade itself takes around 5 minutes.
Nice!! Origin version 8.4 and destination version 9.1.
Unfortunately the post-upgrade analyze of the
On Fri, 2013-08-30 at 11:22 +0200, Andreas Joseph Krogh wrote:
But I agree that returning NULL would be OK, then it would be easy to
catch in queries when starting playing with range-types in queries.
Having it implicitly mean infinity comes as a surprise, to me at
least.
Agreed. This was
On Wed, 2013-08-07 at 23:24 -0700, Chris Travers wrote:
On Wed, Aug 7, 2013 at 9:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
So the obvious question today is whether this isn't
duplicative of the
range datatype stuff. IOW, why wouldn't we be better off to
Hi,
Why is it only possible to store one row by a query which returns multiple rows using the SELECT INTO statement.
and
How can I do a Query on a record varialbe,somehow like this:
SELECT * FROM v_rec
Janek Sendrowski
On 09/01/2013 05:23 PM, Janek Sendrowski wrote:
Hi,
Why is it only possible to store one row by a query which returns
multiple rows using the SELECT INTO statement.
and
How can I do a Query on a record varialbe, somehow like this:
SELECT * FROM v_rec
You can't a record variable can only hold a
To spare memory, you would want to use something like:
insert into test01 select generate_series,
repeat(chr(int4(random()*26)+65),1024) from
generate_series(1,2457600);
Thanks a lot!
What I am worrying about is that:
If data grows rapidly, maybe our customer will use too much memory , Is
=?UTF-8?B?6auY5YGl?= luckyjack...@gmail.com writes:
If data grows rapidly, maybe our customer will use too much memory , Is
ulimit command a good idea for PG?
There's no received wisdom saying that it is. There's a fairly widespread
consensus that disabling OOM kill can be a good idea, but I