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
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
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 TRUNC
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 opt
> 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 applica
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 databa
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 fo
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 research.
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
o
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
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 the
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
"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
Ü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 disc
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 pract
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 Oracl
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
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
"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
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
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 cons
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
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 cont
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 "
-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
"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 e
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 started
> > >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 the
> > 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 some
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
>
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 t
Ü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'
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 i
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
Ü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 u
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 Postg
"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 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 wo
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 a
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 mo
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 datab
"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
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 wh
43 matches
Mail list logo
