Zdenek Kotala wrote:
But how it was mentioned in this thread maybe
somethink like this CREATE TABLESPACE name LOCATION '/my/location'
SEGMENTS 10GB should good solution. If segments is not mentioned then
default value is used.
I think you would need a tool to resegmentize a table or
On Wed, Mar 19, 2008 at 09:38:12AM +0100, Peter Eisentraut wrote:
Another factor I just thought of is that tar, commonly used as part of a
backup procedure, can on some systems only handle files up to 8 GB in size.
There are supposed to be newer formats that can avoid that restriction, but
On Wed, Mar 19, 2008 at 10:51:12AM +0100, Martijn van Oosterhout wrote:
On Wed, Mar 19, 2008 at 09:38:12AM +0100, Peter Eisentraut wrote:
Another factor I just thought of is that tar, commonly used as part of a
backup procedure, can on some systems only handle files up to 8 GB in size.
Petr Jelinek [EMAIL PROTECTED] writes:
Anyway, I am sending second version of the patch.
Applied with minor corrections.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
This has been applied by Tom.
---
Petr Jelinek wrote:
Tom Lane wrote:
Hm, I'm not entirely sure if you got the point or not. For either
relations or composite types, there is both a pg_class entry and a
pg_type
Brendan Jurd [EMAIL PROTECTED] writes:
One of the questions in the original patch submission was whether it
would be worth changing all those DirectFunctionCall(textin) and
(textout) calls to use the new functions. Is it worthwhile avoiding
the fmgr overhead?
I think that's worth doing just
