> > However you cannot currently remove a column...
>
> Oh yes you can:
>
> ALTER TABLE tbl DROP COLUMN whatever
>
> http://www.postgresql.org/docs/view.php?version=7.3&idoc=0&fil
> e=ddl-alter.html
>
> IIRC it was introduced fairly recently (7.3?)
Doh! Really should get rid of 'Practical Post
> You can not change the size but you can increase the number of WAL files
> used.
> See postgresql.conf.
>
> Setting it too high does not achieve anything though. You need to have enough
>
> disk bandwidth to make use of 200MB WAL logs.
I want write a lot of data (large objetcs) without any in
Compression? Postgres tends to compress large fields.
On Fri, Jun 27, 2003 at 10:08:34AM +0200, u15074 wrote:
> I am a little bit confused by the following effect.
> For test reasons I insert about 10 large objects into the database. Each has
> a size of 10240 Bytes (10K). So the expected size
On 27 Jun 2003 at 10:12, u15074 wrote:
> Can I change the size of a wal file, and if so where can I change this? I'd like
> to set the value to bigger value than 16MB.
You can not change the size but you can increase the number of WAL files used.
See postgresql.conf.
Setting it too high does no
Can I change the size of a wal file, and if so where can I change this? I'd like
to set the value to bigger value than 16MB.
Thanks, Andreas.
-
This mail sent through IMP: http://horde.org/imp/
---(end of broadcast)
I am a little bit confused by the following effect.
For test reasons I insert about 10 large objects into the database. Each has
a size of 10240 Bytes (10K). So the expected size of the large object datafile
should be at least 102400 Bytes (about 976MB) just to hold the large objects.
But t
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> I was just looking at that fkey violation message yesterday and thinking how
> much better it would be to be able to see the offending value in the
> message. Is that what 7.4 shows?
You mean like this?
regression=# create table t1 (f1 int primary
On Friday 27 Jun 2003 12:14 pm, Tom Lane wrote:
> Rajesh Kumar Mallah <[EMAIL PROTECTED]> writes:
> > Shudnt' messages like
> > ERROR: value too long for type character varying(5)
> > Indicate which column and table the server is talking about .
>
> Send a patch ;-)
>
I wish i could ;-)
> This
On Fri, 27 Jun 2003, Rajesh Kumar Mallah wrote:
> ...
> similarly when uniq indexes are violated we do not know which
> key is causing it.
>
> MySQL is better in these small things.
>
> I think in 7.4dev fkey violation are reported better,
> cant such behaviours be extened to other kind of
>