On Fri, May 28, 2010 at 2:02 PM, Sakari Maaranen wrote:
> The documentation says that the best way to use autovacuum is to let the
> database vacuum often. However when the tables are very large, this can take
> a very long time.
>
In addition to Tom's comments, as of 8.4 this is no longer true a
Tom Lane wrote:
< NOT NULL constraints at the domain level suck. Don't use 'em.
+1
As someone who uses domains very heavily, I can attest that the
semantics of that are very weak. Whether a domain is nullable
depends almost entirely on the context of its use, which you can't
(and shouldn't
Applied.
---
Bruce Momjian wrote:
> Tom Lane wrote:
> > "Matt Nourse" writes:
> > > CREATE DOMAIN test_id_domain INT NOT NULL;
> > > CREATE TABLE test_state(id test_id_domain PRIMARY KEY, display_value
> > > varchar(20) NO
The following bug has been logged online:
Bug reference: 5483
Logged by: Pascal Van Puymbroeck
Email address: p...@zenonpro.be
PostgreSQL version: 8.3.5 and 8.3.8
Operating system: Centos 5.4
Description:PQescapeStringConn behaviour ??
Details:
Don't know whether th
I have updated the patch, attached, to clarify that this returns text
arrays, and that you can force it to always return one row using
COALESCE() and a '|' pattern (the later suggested by Daniele Varrazzo).
---
Bruce Momjian
"Pascal Van Puymbroeck" writes:
> However if the " ë " character is at the end of a string like the name of a
> country in dutch "Italië" this PQescapeStringConn function adds two
> spaces. so "België" becomes "België ". The error is set to 1 which
> indicates we can't trust the outcome.
2010/5/29 Greg Stark :
> On Fri, May 28, 2010 at 2:02 PM, Sakari Maaranen wrote:
>> The documentation says that the best way to use autovacuum is to let the
>> database vacuum often. However when the tables are very large, this can take
>> a very long time.
>
> In addition to Tom's comments, as of
On Sat, May 29, 2010 at 5:00 PM, Bruce Momjian wrote:
> I have updated the patch, attached, to clarify that this returns text
> arrays, and that you can force it to always return one row using
> COALESCE() and a '|' pattern (the later suggested by Daniele Varrazzo).
I don't find this part to be s
On Sat, May 29, 2010 at 5:44 PM, Sakari A. Maaranen wrote:
> For now, I can work around this on the client side by splitting the
> updates into a million separate transactions instead of a single big
> one. Will be slow, but it should work.
In general, it's better to group things into larger tran
