Disable Transaction - plans ?
Hi
Is there any plan to relase a version which allow the user to disable the
use of transactions on some of the tables ?
--------------------------
Canaan Surfing Ltd.
Internet Service Providers
Ben-Nes Michael - Manager
Tel: 972-4-6991122
http://sites.canaan.co.il
--------------------------
On Wed, Oct 24, 2001 at 11:23:49AM +0200, Ben-Nes Michael wrote:
Hi
Is there any plan to relase a version which allow the user to disable the
use of transactions on some of the tables ?
And what would be the use of that?
Perhaps you should explain your problem because what you are asking not a
solution to anything.
HTH,
--
Martijn van Oosterhout <kleptog@svana.org>
http://svana.org/kleptog/
Show quoted text
Magnetism, electricity and motion are like a three-for-two special offer:
if you have two of them, the third one comes free.
Simple.
In my dynamic sites I have sessions tables that get select/update/insert
allot, So removing as many obstacles from select/update/insert against "very
simple" tables will improve the performance.
--------------------------
Canaan Surfing Ltd.
Internet Service Providers
Ben-Nes Michael - Manager
Tel: 972-4-6991122
http://sites.canaan.co.il
--------------------------
----- Original Message -----
From: "Martijn van Oosterhout" <kleptog@svana.org>
To: "Ben-Nes Michael" <miki@canaan.co.il>
Cc: <pgsql-general@postgresql.org>
Sent: Wednesday, October 24, 2001 12:13 PM
Subject: Re: [GENERAL] Disable Transaction - plans ?
On Wed, Oct 24, 2001 at 11:23:49AM +0200, Ben-Nes Michael wrote:
Hi
Is there any plan to relase a version which allow the user to disable
the
use of transactions on some of the tables ?
And what would be the use of that?
Perhaps you should explain your problem because what you are asking not a
solution to anything.HTH,
--
Martijn van Oosterhout <kleptog@svana.org>
http://svana.org/kleptog/Magnetism, electricity and motion are like a three-for-two special
offer:
Show quoted text
if you have two of them, the third one comes free.
On Wed, Oct 24, 2001 at 12:32:06PM +0200, Ben-Nes Michael wrote:
Simple.
In my dynamic sites I have sessions tables that get select/update/insert
allot, So removing as many obstacles from select/update/insert against "very
simple" tables will improve the performance.
Well, I think you may be barking up the wrong tree. The overhead for
transactions is very low. You are under the impression that that
transactions slow the database down?
Removing transactions would basically remove the whole point of having an
RDBMS. Seriously, transactions are no performance impediment.
--
Martijn van Oosterhout <kleptog@svana.org>
http://svana.org/kleptog/
Show quoted text
Magnetism, electricity and motion are like a three-for-two special offer:
if you have two of them, the third one comes free.
...
Is there any plan to relase a version which allow the user to disable the
use of transactions on some of the tables ?
No. We also have no plans to break other fundamental RDBMS features.
Why would you want such a thing?
- Thomas
On Wed, 24 Oct 2001, Thomas Lockhart wrote:
Is there any plan to relase a version which allow the user to disable the
use of transactions on some of the tables ?No. We also have no plans to break other fundamental RDBMS features.
Why would you want such a thing?
Speed? :) (smirk)
--
Dominic J. Eidson
"Baruk Khazad! Khazad ai-menu!" - Gimli
-------------------------------------------------------------------------------
http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/
If performance is slowing down, I suggest you run VACUUM or VACUUM ANALYZE
once a day.
In addition, you can turn DBI's AutoCommit (assuming this is what you are
using to connect to Postgres) to on, which will end the transaction block
and unlock the table for VACUUM.
Without knowing your configuration or your performance problem, it is hard
to make any further suggestions.
Mark
Epilogue.net
Simple.
In my dynamic sites I have sessions tables that get select/update/insert
allot, So removing as many obstacles from select/update/insert against
"very
simple" tables will improve the performance.
--------------------------
Canaan Surfing Ltd.
Internet Service Providers
Ben-Nes Michael - Manager
Tel: 972-4-6991122
http://sites.canaan.co.il
------------------------------- Original Message -----
From: "Martijn van Oosterhout" <kleptog@svana.org>
To: "Ben-Nes Michael" <miki@canaan.co.il>
Cc: <pgsql-general@postgresql.org>
Sent: Wednesday, October 24, 2001 12:13 PM
Subject: Re: [GENERAL] Disable Transaction - plans ?On Wed, Oct 24, 2001 at 11:23:49AM +0200, Ben-Nes Michael wrote:
Hi
Is there any plan to relase a version which allow the user to disable
the
use of transactions on some of the tables ?
And what would be the use of that?
Perhaps you should explain your problem because what you are asking not
a
Show quoted text
solution to anything.
HTH,
--
Martijn van Oosterhout <kleptog@svana.org>
http://svana.org/kleptog/Magnetism, electricity and motion are like a three-for-two special
offer:
if you have two of them, the third one comes free.
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
"Dominic J. Eidson" <sauron@the-infinite.org> writes:
On Wed, 24 Oct 2001, Thomas Lockhart wrote:
Is there any plan to relase a version which allow the user to disable the
use of transactions on some of the tables ?No. We also have no plans to break other fundamental RDBMS features.
Why would you want such a thing?
Speed? :) (smirk)
If you want MySQL, you know where to find it. ;)
-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863
Import Notes
Reply to msg id not found: DominicJ.Eidson'smessageofWed24Oct2001091800-0500CDT
...
Speed? :) (smirk)
If you want MySQL, you know where to find it. ;)
Hmm. Assuming that "speed" is the outcome of dropping transaction
support is a bit simplistic (and linking "speed" and "mysql" and "no
transactions" has been shown to be a hollow argument). In fact, without
transactions (or with a transaction for every query) you see the full
effects of requiring a "commit" at every query. Buffers must be written
and everything having to do with the query must be cleaned up. With
transactions, some of those steps are postponed until commit, and you
will see a per-query performance gain by lumping many queries into one
transaction.
Also, without transactions and without MVCC, you must tightly coordinate
every query and every affected row in every table, which can choke off
performance as you scale to larger numbers of clients.
- Thomas
No, I don't want MySQL I want specific few chosen tables to be without
transaction like: session table
All the other tables (95%) must have transaction ... foreign keys ....
inherits ... views .......
I think it can be very beneficial to chop of portion of the code or even
implant another system of tables into Postgres that will enable the most
simplest fastest query.
If the developers think that the speed increase is irrelevant then lets drop
the issue :)
--------------------------
Canaan Surfing Ltd.
Internet Service Providers
Ben-Nes Michael - Manager
Tel: 972-4-6991122
http://sites.canaan.co.il
--------------------------
----- Original Message -----
From: "Doug McNaught" <doug@wireboard.com>
To: "Dominic J. Eidson" <sauron@the-infinite.org>
Cc: <thomas@pgsql.com>; "Ben-Nes Michael" <miki@canaan.co.il>;
<pgsql-general@postgresql.org>
Sent: Wednesday, October 24, 2001 6:12 PM
Subject: Re: [GENERAL] Disable Transaction - plans ?
"Dominic J. Eidson" <sauron@the-infinite.org> writes:
On Wed, 24 Oct 2001, Thomas Lockhart wrote:
Is there any plan to relase a version which allow the user to
disable the
Show quoted text
use of transactions on some of the tables ?
No. We also have no plans to break other fundamental RDBMS features.
Why would you want such a thing?
Speed? :) (smirk)
If you want MySQL, you know where to find it. ;)
-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863
...
If the developers think that the speed increase is irrelevant then lets drop
the issue :)
No problem. We will be happy to entertain patches or demonstrations that
show a clear benefit in speed for the changes you suggest.
- Thomas
On Wed, 24 Oct 2001, Thomas Lockhart wrote:
...
Speed? :) (smirk)
If you want MySQL, you know where to find it. ;)
Hmm. Assuming that "speed" is the outcome of dropping transaction
support is a bit simplistic (and linking "speed" and "mysql" and "no
transactions" has been shown to be a hollow argument). In fact, without
In case it escaped a bunch of people - my "Speed?" comment was
tongue-in-cheek making fun of the MySQL crowd...
--
Dominic J. Eidson
"Baruk Khazad! Khazad ai-menu!" - Gimli
-------------------------------------------------------------------------------
http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/
Thomas Lockhart wrote:
...
Speed? :) (smirk)
If you want MySQL, you know where to find it. ;)
Hmm. Assuming that "speed" is the outcome of dropping transaction
support is a bit simplistic (and linking "speed" and "mysql" and "no
transactions" has been shown to be a hollow argument). In fact, without
transactions (or with a transaction for every query) you see the full
effects of requiring a "commit" at every query. Buffers must be written
and everything having to do with the query must be cleaned up. With
transactions, some of those steps are postponed until commit, and you
will see a per-query performance gain by lumping many queries into one
transaction.Also, without transactions and without MVCC, you must tightly coordinate
every query and every affected row in every table, which can choke off
performance as you scale to larger numbers of clients.
In fact, some could argue that the default behavior of PostgreSQL
should be changed (or at least have an option) to behave like
Oracle, where a transaction is implicitly begun at the first
encounter of an INSERT/UPDATE/DELETE - or in PostgreSQL's case, the
first submitted statement. That would make PostgreSQL behave much
better out-of-the-box in comparison to mySQL, and would satiate the
desires of those Oracle folks transitioning to PostgreSQL that do a:
DELETE FROM foo;
-- Nuts!
ROLLBACK;
and expect their DELETE to be undone.
FWIW,
Mike Mascari
mascarm@mascari.com
If the developers think that the speed increase is irrelevant then lets drop
the issue :)No problem. We will be happy to entertain patches or demonstrations that
show a clear benefit in speed for the changes you suggest.
Speed and memory efficiency used to be big issues, but I think now
fast hardware is so absurdly cheap that things like stability and
other features are more important than speed. I think that's why
people are doing a lot of server stuff in java. It's definitely slow,
but it's also more solid and lets you develop more flexibly, and
that's more important than speed.
In case it escaped a bunch of people - my "Speed?" comment was
tongue-in-cheek making fun of the MySQL crowd...
It didn't escape me, but I didn't want to focus on the fact that you
might be needling someone... ;)
And for someone not familiar with the past discussions, they *might*
have thought you were serious!
- Thomas
Mike Mascari <mascarm@mascari.com> writes:
In fact, some could argue that the default behavior of PostgreSQL
should be changed (or at least have an option) to behave like
Oracle, where a transaction is implicitly begun at the first
encounter of an INSERT/UPDATE/DELETE - or in PostgreSQL's case, the
first submitted statement.
If we put in an implicit BEGIN at the start of a connection, when
does it get committed? We certainly dare not do an implicit COMMIT
when the client disconnects, but without that the change would
completely break a lot of existing applications.
Personally I'm perfectly happy with the notion that clients who want
this behavior can send a BEGIN for themselves ...
regards, tom lane
In fact, some could argue that the default behavior of PostgreSQL
should be changed (or at least have an option) to behave like
Oracle, where a transaction is implicitly begun at the first
encounter of an INSERT/UPDATE/DELETE - or in PostgreSQL's case, the
first submitted statement.If we put in an implicit BEGIN at the start of a connection, when
does it get committed? We certainly dare not do an implicit COMMIT
when the client disconnects, but without that the change would
completely break a lot of existing applications.
Ingres solved this with a mode switch; "set autocommit on|off" which is
in the style that we would likely use too. It *should* be optional, but
settable, and we can debate which should be the default later.
When autocommit is "off", the transaction gets committed when you exit
or when you explicitly commit.
- Thomas
Thomas Lockhart <lockhart@fourpalms.org> writes:
When autocommit is "off", the transaction gets committed when you exit
or when you explicitly commit.
Only when you explicitly commit, please. Autocommit when we lose the
client connection is not acceptable, even if the client thinks he
wants it.
regards, tom lane
Only when you explicitly commit, please. Autocommit when we lose the
client connection is not acceptable, even if the client thinks he
wants it.
There is a client-side termination handshake, and it could be tied to
that. If we can distinguish between an intentional exit and an
unexpected termination, then istm that a commit would be safe to apply
for the former.
I'm recalling that this is the behavior of Ingres, but it has been a few
years since I've dealt with it...
- Thomas
Thomas Lockhart <lockhart@fourpalms.org> writes:
There is a client-side termination handshake, and it could be tied to
that. If we can distinguish between an intentional exit and an
unexpected termination, then istm that a commit would be safe to apply
for the former.
I assert that we cannot safely determine that; it's too easy for a
client logic error to tell libpq to close the connection at the wrong
time, and we should NOT default to committing when that happens.
I think a client using this mode should be expected to send an explicit
commit command before exiting.
regards, tom lane
