Florian G. Pflug wrote:
Alvaro Herrera wrote:
Florian G. Pflug wrote:
However, I just realized that doing this is much harder than I initially
thought, because catalog access always happens with SnapshotNow, and
e.g. drop table deletes datafiles at commit time, and not during
vacuum.
Not
Do 97% of transactions commit because Oracle has slow rollbacks and
developers are working around that performance issue, or because they
really commit?
I have watched several developers that would prefer to issue numerous
selects to verify things like foreign keys in the application
Theo Schlossnagle wrote:
On Feb 20, 2007, at 1:40 PM, Tom Lane wrote:
RPK [EMAIL PROTECTED] writes:
I did not mean asking for undo from a life-time log. Since FlashBack
Technology is already there, I just mean that world's most advanced
database
(PostgreSQL, as they say), must have an
Florian G. Pflug wrote:
However, I just realized that doing this is much harder than I initially
thought, because catalog access always happens with SnapshotNow, and
e.g. drop table deletes datafiles at commit time, and not during vacuum.
Not to mention the likenesses of CLUSTER and TRUNCATE,
Alvaro Herrera wrote:
Florian G. Pflug wrote:
However, I just realized that doing this is much harder than I initially
thought, because catalog access always happens with SnapshotNow, and
e.g. drop table deletes datafiles at commit time, and not during vacuum.
Not to mention the likenesses
Jonah H. Harris [EMAIL PROTECTED] writes:
On 2/17/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
My understanding is that the main difference is that rollbacks are
inexpensive for us, but expensive for Oracle.
Yes, Oracle is optimized for COMMIT, we're optimized for ROLLBACK :)
I used to say
I agree that TimeStamp creates an overhead, but I just want to know if an
accidental update happened to a table and this incident got traced three
days after, what facility PGSQL provide to bring the table to its original
condition. You can't wait regretting on why you did not run ROLLBACK before
RPK wrote:
I agree that TimeStamp creates an overhead, but I just want to know if an
accidental update happened to a table and this incident got traced three
days after, what facility PGSQL provide to bring the table to its original
condition. You can't wait regretting on why you did not run
On 2/20/07, Gregory Stark [EMAIL PROTECTED] wrote:
I used to say that too but I've since realized it's not really true.
Heh, take a joke man... I was following up on Drake's email :)
But, since you want to discuss your view of the systems openly... I'll
gladly reply :)
It's more like Oracle
Wrong. When Oracle says it's committed, it's committed. No
difference between when, where, and how. In Oracle, the committed
version is *always* the first presented to the user... it takes time
to go back and look at older versions; but why shouldn't that be a bit
slower, it isn't common
Ühel kenal päeval, T, 2007-02-20 kell 10:20, kirjutas Jonah H. Harris:
On 2/20/07, Gregory Stark [EMAIL PROTECTED] wrote:
I used to say that too but I've since realized it's not really true.
Heh, take a joke man... I was following up on Drake's email :)
But, since you want to discuss your
Jonah H. Harris [EMAIL PROTECTED] writes:
On 2/20/07, Gregory Stark [EMAIL PROTECTED] wrote:
It's more like Oracle is optimized for data that's committed
long in the past and we're optimized for data that's
been recently updated.
Wrong. When Oracle says it's committed, it's committed. No
Tom Lane wrote:
August Zajonc [EMAIL PROTECTED] writes:
The key is how lightweight the setup could be, which matters because
clients are not always willing to pay for a PITR setup. The low overhead
would mean you'd feel fine about setting guc to 1hr or so.
This would have exactly the same
Andrew,
Demanding unlimited undo at some time that is arbitrarilly distant in the
future strikes me as wholly unreasonable.
I did not mean asking for undo from a life-time log. Since FlashBack
Technology is already there, I just mean that world's most advanced database
(PostgreSQL, as they
RPK [EMAIL PROTECTED] writes:
I did not mean asking for undo from a life-time log. Since FlashBack
Technology is already there, I just mean that world's most advanced database
(PostgreSQL, as they say), must have an optimized way for undoing of at
least a week changes.
You're living in a
On Feb 20, 2007, at 1:40 PM, Tom Lane wrote:
RPK [EMAIL PROTECTED] writes:
I did not mean asking for undo from a life-time log. Since FlashBack
Technology is already there, I just mean that world's most
advanced database
(PostgreSQL, as they say), must have an optimized way for undoing
of
On 2/20/07, Rod Taylor [EMAIL PROTECTED] wrote:
Do 97% of transactions commit because Oracle has slow rollbacks and
developers are working around that performance issue, or because they
really commit?
Again, off-topic, but 97% of all transactions commit according to Jim
Gray and his
On 2/20/07, Hannu Krosing [EMAIL PROTECTED] wrote:
He probably meant longer transactions and several versions visible to
different backends.
Yes, he may have... but I was responding to the statements he made.
but why shouldn't that be a bit slower, it isn't common practice anyway.
Not for
RPK wrote:
Andrew,
Demanding unlimited undo at some time that is arbitrarilly distant in the
future strikes me as wholly unreasonable.
I did not mean asking for undo from a life-time log. Since FlashBack
Technology is already there, I just mean that world's most advanced database
Hello,
On Sat, 17 Feb 2007 06:49:42 -0800 (PST)
RPK [EMAIL PROTECTED] wrote:
PostgreSQL, already a mature database, needs to have more options for
recovery as compared to proprietary databases. I just worked with Oracle's
FlashBack query feature in Oracle 9i and FlashBack Table feature in
Ühel kenal päeval, P, 2007-02-18 kell 14:27, kirjutas Joshua D. Drake:
Hannu Krosing wrote:
Ühel kenal päeval, L, 2007-02-17 kell 22:49, kirjutas Chad Wagner:
However, they don't have vacuum, we do.
Right, and I think that is more or less because Oracle doesn't need
it.
Hannu Krosing wrote:
Ühel kenal päeval, P, 2007-02-18 kell 14:27, kirjutas Joshua D. Drake:
Hannu Krosing wrote:
Ühel kenal päeval, L, 2007-02-17 kell 22:49, kirjutas Chad Wagner:
To get a flashback query, you just have to construct a snapshot from
that time and you are done. We don't store
Florian G. Pflug escribió:
Hannu Krosing wrote:
Ühel kenal päeval, P, 2007-02-18 kell 14:27, kirjutas Joshua D. Drake:
Hannu Krosing wrote:
Ühel kenal päeval, L, 2007-02-17 kell 22:49, kirjutas Chad Wagner:
To get a flashback query, you just have to construct a snapshot from
that time and
Well this is certainly interesting. What do we think it
would take to
enable the functionality?
First we must run the query in serializable mode and replace
the snapshot with a synthetic one, which defines visibility
at the start of the desired transaction
We could use something
First we must run the query in serializable mode and replace the
snapshot with a synthetic one, which defines visibility at the
start
of the desired transaction
probably it is a good idea to take a lock on all tables involved to
avoid a vacuum to be started on them when the query
Zeugswetter Andreas ADI SD wrote:
First we must run the query in serializable mode and replace the
snapshot with a synthetic one, which defines visibility at the
start
of the desired transaction
probably it is a good idea to take a lock on all tables involved to
avoid a vacuum to be
Zeugswetter Andreas ADI SD [EMAIL PROTECTED] writes:
First we must run the query in serializable mode and replace
the snapshot with a synthetic one, which defines visibility
at the start of the desired transaction
We could use something that controls global xmin.
It would ensure, that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Feb 19, 2007 at 04:00:09PM +0100, Florian G. Pflug wrote:
[...]
In the long run, you'd probably want to store the commit-times of
transactions somewhere, and add some guc that makes a vacuum assume
that recently comitted transaction (say,
Gregory Stark wrote:
Zeugswetter Andreas ADI SD [EMAIL PROTECTED] writes:
First we must run the query in serializable mode and replace
the snapshot with a synthetic one, which defines visibility
at the start of the desired transaction
We could use something that controls global xmin.
It
August Zajonc wrote:
Gregory Stark wrote:
Zeugswetter Andreas ADI SD [EMAIL PROTECTED] writes:
First we must run the query in serializable mode and replace
the snapshot with a synthetic one, which defines visibility
at the start of the desired transaction
We could use something that
On Mon, 19 Feb 2007 20:30:59 +0100, Florian G. Pflug [EMAIL PROTECTED]
said:
August Zajonc wrote:
Gregory Stark wrote:
Couldn't you define things simply to be that you get a consistent view
including all transactions started before x transaction? This is time
travel lite, but low
August Zajonc [EMAIL PROTECTED] writes:
The key is how lightweight the setup could be, which matters because
clients are not always willing to pay for a PITR setup. The low overhead
would mean you'd feel fine about setting guc to 1hr or so.
This would have exactly the same performance
On 2/17/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
My understanding is that the main difference is that rollbacks are
inexpensive for us, but expensive for Oracle.
Yes, Oracle is optimized for COMMIT, we're optimized for ROLLBACK :)
In all seriousness, last time I checked Oracle's MVCC was
Ühel kenal päeval, L, 2007-02-17 kell 22:49, kirjutas Chad Wagner:
However, they don't have vacuum, we do.
Right, and I think that is more or less because Oracle doesn't need
it. Vacuum's main purpose (correct me if I am wrong) is to
recover/mark rows that are no longer used,
Hannu Krosing wrote:
Ühel kenal päeval, L, 2007-02-17 kell 22:49, kirjutas Chad Wagner:
However, they don't have vacuum, we do.
Right, and I think that is more or less because Oracle doesn't need
it. Vacuum's main purpose (correct me if I am wrong) is to
recover/mark rows that
PostgreSQL, already a mature database, needs to have more options for
recovery as compared to proprietary databases. I just worked with Oracle's
FlashBack query feature in Oracle 9i and FlashBack Table feature in 10g.
Future versions of PostgreSQL must have similar features which enable users
to
RPK wrote:
PostgreSQL, already a mature database, needs to have more options for
recovery as compared to proprietary databases. I just worked with Oracle's
FlashBack query feature in Oracle 9i and FlashBack Table feature in 10g.
Future versions of PostgreSQL must have similar features which
Joshua D. Drake [EMAIL PROTECTED] writes:
RPK wrote:
Future versions of PostgreSQL must have similar features which enable users
to bring Table(s) and/or Database(s) to a desired Time Stamp.
We can do it with databases, we can't do it with tables. Nor should we
do it with tables as it would
On Sat, Feb 17, 2007 at 11:48:55AM -0500, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
RPK wrote:
Future versions of PostgreSQL must have similar features which enable users
to bring Table(s) and/or Database(s) to a desired Time Stamp.
We can do it with databases, we can't
On 2/17/07, elein [EMAIL PROTECTED] wrote:
For other recent time travel ideas see:
http://www.varlena.com/GeneralBits/122.php
Time travel is not cheap, though.
I am sure this topic has probably been beaten to death in the past, but has
anyone talked about the advantages of Oracle's MVCC
Chad Wagner wrote:
On 2/17/07, elein [EMAIL PROTECTED] wrote:
For other recent time travel ideas see:
http://www.varlena.com/GeneralBits/122.php
Time travel is not cheap, though.
I am sure this topic has probably been beaten to death in the past, but has
anyone talked about the
On 2/17/07, Joshua D. Drake [EMAIL PROTECTED] wrote:
My understanding is that the main difference is that rollbacks are
inexpensive for us, but expensive for Oracle. Talk to an Oracle DBA
about their Rollback logs :0.
Yes, I have seen cases where undo segments are thrashed. Generally it
Chad Wagner [EMAIL PROTECTED] writes:
I am sure this topic has probably been beaten to death in the past, but has
anyone talked about the advantages of Oracle's MVCC model versus
PostgreSQL's MVCC model?
Yes, we've been all through that. We like ours. See the archives.
On Saturday 17 February 2007 07:49, RPK wrote:
PostgreSQL, already a mature database, needs to have more options for
recovery as compared to proprietary databases. I just worked with Oracle's
FlashBack query feature in Oracle 9i and FlashBack Table feature in 10g.
Future versions of
44 matches
Mail list logo
