I have been a long time user of mysql. Switching to Postgresql because
the true features included in 5.1 (as of this moment) are nothing to
write home about. The InnoDB stuff is highly advocated but it has its
own set of issues, and when one looks at things like backup/restore
etc, it is clearly
Phoenix Kiula [EMAIL PROTECTED] writes:
Though other threads I have learned that multiple inserts or updates
can be sped up with:
[QUOTE]
- BEGIN TRANSACTION;
- INSERT OR UPDATE queries, ideally PREPAREd;
- COMMIT;
[/QUOTE]
QUESTION1:
Is this it? Or am I missing something in terms of
On 14/08/07, Gregory Stark [EMAIL PROTECTED] wrote:
Phoenix Kiula [EMAIL PROTECTED] writes:
Though other threads I have learned that multiple inserts or updates
can be sped up with:
[QUOTE]
- BEGIN TRANSACTION;
- INSERT OR UPDATE queries, ideally PREPAREd;
- COMMIT;
[/QUOTE]
On Tue, Aug 14, 2007 at 11:09:36PM +0800, Phoenix Kiula wrote:
If I am reading this right, does this mean it is probably better to
leave fsync as fsync=off on production machines?
No, you want fsync=on on any machine which holds data you
care about. And you want hardware which doesn't lie to
Thank you AM. Very useful note, must appreciate the info you shared.
About COPY, I have two simple questions:
1. Is there anything like an ALTER DATABASE command? I would like to
change the character set without having to recreate the DATABASE
again!
2. Also, when I do a mysqldump I seem to be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/14/07 10:09, Phoenix Kiula wrote:
On 14/08/07, Gregory Stark [EMAIL PROTECTED] wrote:
Phoenix Kiula [EMAIL PROTECTED] writes:
[snip]
QUESTION1:
Is this it? Or am I missing something in terms of execution? We use
Perl on our site but may
Phoenix Kiula [EMAIL PROTECTED] writes:
If I am reading this right, does this mean it is probably better to
leave fsync as fsync=off on production machines?
Only if you can reconstruct your data from other sources in the case of a
server crash or power failure. I wouldn't recommend it.
Phoenix Kiula wrote:
Agree. That's what I am trying to do. Include as many UPDATEs etc into
the same TRANSACTION block, but my worry is when I read about
autocommit and how it is enabled by default in postgresql 8.
Specifying explicit BEGIN and COMMIT blocks should only commit when I
want the
On 8/14/07, Alban Hertroys [EMAIL PROTECTED] wrote:
*And* you can define compound foreign key constraints,
for example:
CREATE TABLE employee (
employee_id serial NOT NULL,
company_id integer NOT NULL,
name text NOT NULL,
CONSTRAINT employee_pk
You're confusing CHECK constraints and FOREIGN KEY constraints. They're
different things ;)
CHECK constraints verify that data in a certain column matches a certain
condition. I'm not sure they can reference columns in other tables,
unless you wrap those checks in stored procedures maybe...
If you issue a BEGIN then nothing gets committed until you issue a COMMIT. If
anything happens in the meantime then everything you've done since the BEGIN
disappears.
There are some cases where I would like to bunch queries into a
transaction purely for speed purposes, but they're not
In response to Phoenix Kiula [EMAIL PROTECTED]:
If you issue a BEGIN then nothing gets committed until you issue a COMMIT.
If
anything happens in the meantime then everything you've done since the BEGIN
disappears.
There are some cases where I would like to bunch queries into a
Phoenix Kiula wrote on 14.08.2007 19:46:
There are some cases where I would like to bunch queries into a
transaction purely for speed purposes, but they're not interdependent
for integrity. E.g.,
BEGIN TRANSACTION;
UPDATE1;
UPDATE2;
UPDATE3;
COMMIT;
If UPDATE2 fails because it, say,
On 8/14/07, Bill Moran [EMAIL PROTECTED] wrote:
But the rule is, if any query within the transaction errors, then all
queries
within the transaction are rolled back.
This is the default behaviour, but with psql and ON_ERROR_ROLLBACK parameter
the behaviour can be changed. See
You could do this with savepoints which are a kind of sub-transaction inside a
bigger transaction.
e.g.:
BEGIN TRANSACTION;
SAVEPOINT sp1;
UPDATE1;
IF (failed) rollback to savepoint sp1;
SAVEPOINT sp1;
UPDATE2;
IF (failed) rollback to savepoint sp2;
Thanks Thomas, this is a great
Phoenix Kiula [EMAIL PROTECTED] writes:
There are some cases where I would like to bunch queries into a
transaction purely for speed purposes, but they're not interdependent
for integrity. E.g.,
How do you know you need to do this for speed if you haven't run it yet? I
would suggest you build
On 8/14/07, Phoenix Kiula [EMAIL PROTECTED] wrote:
*And* you can define compound foreign key constraints,
Thank you for this detailed explanation Alban. But I want to include
FK constraints on a table2 on a column in the referenced table1 where
column values are not unique.
I just want
On 8/14/07, Phoenix Kiula [EMAIL PROTECTED] wrote:
Thank you for this detailed explanation Alban. But I want to include
FK constraints on a table2 on a column in the referenced table1 where
column values are not unique.
I just want row data to be consistent for the same ID. Yes, this is
18 matches
Mail list logo
