Hi,
I have noticed that the first time you execute an:
update table1 set params_count=0;
it takes too long to complete: 11000 rows - 100 s.
Postgresql 8.3 configuration on Turion 64 with 1.4 Gb RAM, Windows XP
Which compiler is used to build Postgresql on Windows? Is it 9?
Any comment?
Che
On Sat, Apr 19, 2008 at 10:14:00AM +0530, Jaisen N.D. wrote:
> Hi., Sorry for my late reply, I wasn't on desk for last few days. My goal is
> to set up a spatial database, with postgresql 8.1. I removed the postgresql
> installation using apt-get --purge remove. and removed the
> var/lib/postgresql
On Tue, Apr 15, 2008 at 01:11:10PM -0700, Ralph Smith wrote:
> I need to do a simple query and output to a file.
> No problem.
>
> But how do I encrypt one column's output?
COPY (SELECT a, b, c, some_func(d) AS d_s3krit FROM your_tab) TO...;
Does that help?
Cheers,
David.
> There are lots of dev
On Sat, Apr 19, 2008 at 1:33 AM, Anton Andreev <[EMAIL PROTECTED]> wrote:
> update table1 set params_count=0;
> it takes too long to complete: 11000 rows - 100 s.
> Postgresql 8.3 configuration on Turion 64 with 1.4 Gb RAM, Windows XP
> Which compiler is used to build Postgresql on Windows? Is
HI everyone,
I´m trying to capture all the possible errors that a statement can have.
And, if there´s any error i will do a rollback; What i´m trying to do its:
BEGIN
insert into temp values(1, 2, 3);
IF ANY_ERROR_OCCURED THEN
ROLLBACK;
RETURN FALSE;
END IF;
END;
Did anyone knows
Hi all
I've chucked together a quick and very ugly script to read the .po files
from the backend and produce a simple database to map translations back
to the original strings and their source locations. It's a very dirty
.po reader that doesn't try to parse the format properly, but it does
t
Anton Andreev wrote:
Hi,
I have noticed that the first time you execute an:
update table1 set params_count=0;
it takes too long to complete: 11000 rows - 100 s.
Postgresql 8.3 configuration on Turion 64 with 1.4 Gb RAM, Windows XP
Which compiler is used to build Postgresql on Windows? Is it
On Sat, Apr 19, 2008 at 11:47:19AM -0300, x asasaxax wrote:
> I´m trying to capture all the possible errors that a statement can have.
> And, if there´s any error i will do a rollback; What i´m trying to do its:
What are you trying to do? Any error automatically rolls back the
transaction, so:
>
x asasaxax wrote:
HI everyone,
I´m trying to capture all the possible errors that a statement can have.
And, if there´s any error i will do a rollback; What i´m trying to do its:
BEGIN
insert into temp values(1, 2, 3);
IF ANY_ERROR_OCCURED THEN
ROLLBACK;
RETURN FALSE;
END IF;
EN
x asasaxax wrote:
HI everyone,
I´m trying to capture all the possible errors that a statement can have.
And, if there´s any error i will do a rollback; What i´m trying to do its:
BEGIN
insert into temp values(1, 2, 3);
IF ANY_ERROR_OCCURED THEN
ROLLBACK;
Sorry, I didn't see the ROLLB
Craig Ringer <[EMAIL PROTECTED]> writes:
> It's also useful for format-string based messages, but more thought is
> needed on how best to handle them. A LIKE query using the format-string
> message as the pattern (after converting the pattern syntax to SQL
> style) would be (a) slow and (b) very
Tom Lane wrote:
I don't really see the problem. I assume from your reference to pg_trgm
that you're using trigram similarity as the prefilter for potential
matches
It turns out that's no good anyway, as it appears to ignore characters
outside the ASCII range. Rather less than useful for sear
Craig Ringer <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I don't really see the problem. I assume from your reference to pg_trgm
>> that you're using trigram similarity as the prefilter for potential
>> matches
> It turns out that's no good anyway, as it appears to ignore characters
> outsi
On Sat, 19 Apr 2008, Tom Lane wrote:
Craig Ringer <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I don't really see the problem. I assume from your reference to pg_trgm
that you're using trigram similarity as the prefilter for potential
matches
It turns out that's no good anyway, as it appear
Tom Lane wrote:
True. It's not so much the speed as the fragility when faced with small
changes to formatting. In addition to whitespace, some clients mangle
punctuation with features like automatic "curly"-quoting.
Yeah. I was wondering whether encoding differences wouldn't be a huge
proble
On Apr 18, 2008, at 2:00 PM, Bayless Kirtley wrote:
First, I am new to Postgres. I am hoping to migrate an existing
Java application from a couple of tried but unreliable open source
Java databases. I have a fair amount of experience with Oracle,
Informix and DB2 but it has been a few years.
On Apr 18, 2008, at 2:42 PM, Chris Browne wrote:
However, it is unusual for a database to consist of just one table of
that sort. If you have a case like this, it will make plenty of sense
to split this set of tables into pieces, and add them in at least
somewhat incrementally.
Does anyone ha
On Apr 18, 2008, at 2:18 PM, Alvaro Herrera wrote:
Actually, electrons themselves flow rather slowly -- millimeters per
second according to Wikipedia. The signal propagation is a bit
faster:
"typically 75% of light speed", Wikipedia again.
Yeah, electrons move *very* slowly in a solid. Pre
18 matches
Mail list logo