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 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
> invent
> i
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
ul
=?UTF-8?B?6auY5YGl?= 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 don't recall
that man
