On Tue, 23 Oct 2007 09:07:52 -0400
"Jonah H. Harris" <[EMAIL PROTECTED]> wrote:
> On 10/23/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> > It would be a major mistake to think there's no work left to
> > do in improving update performance.
>
> Agreed. That would be a very short-sighted move.
>
On 10/23/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> Don't *need* would be better.
Forgot to mention I agree. What's done is done. I'm not beating that
UNDO horse anymore; it's long past dead.
--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation
On 10/23/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> It would be a major mistake to think there's no work left to
> do in improving update performance.
Agreed. That would be a very short-sighted move.
--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation
On 10/23/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > We never actually considred undo
>
> I did, but eventually ruled it out during the HOT design process. But
> then I considered a ton of other things and ruled them out also.
>
> Can't see a reason to bring it up again, so perhaps we should add
On Mon, 2007-10-22 at 11:00 -0400, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > Josh Berkus wrote:
> > > Bruce Momjian wrote:
> > >> Those who have been with the community from long ago might remember
> > >> discussion about implementing a undo log. The big advantage of this is
> > >> that it
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> HOT is cool, but it really doesn't solve the whole problem. It works for a
> significant class of problems, but for example it won't have any significant
> effect on the app I'm currently working on which is very index-rich. It would
> be a major mist
Bruce Momjian wrote:
Josh Berkus wrote:
Bruce,
We never actually considred undo, but high UPDATE activity was one of
the areas we historically handled poorly compared to undo systems, and
undo would have been one way to improve that area. I think with HOT we
have improved high UPDAT
Josh Berkus wrote:
> Bruce,
>
> > We never actually considred undo, but high UPDATE activity was one of
> > the areas we historically handled poorly compared to undo systems, and
> > undo would have been one way to improve that area. I think with HOT we
> > have improved high UPDATE activity enou
Bruce,
We never actually considred undo, but high UPDATE activity was one of
the areas we historically handled poorly compared to undo systems, and
undo would have been one way to improve that area. I think with HOT we
have improved high UPDATE activity enough that the undo benefits are no
long
Joshua D. Drake wrote:
> Josh Berkus wrote:
> > Bruce Momjian wrote:
> >> Those who have been with the community from long ago might remember
> >> discussion about implementing a undo log. The big advantage of this is
> >> that it allows UPDATE to _replace_ rows and limits the amount of cleanup
>
Josh Berkus wrote:
Bruce Momjian wrote:
Those who have been with the community from long ago might remember
discussion about implementing a undo log. The big advantage of this is
that it allows UPDATE to _replace_ rows and limits the amount of cleanup
required for UPDATEs.
I am hoping that wit
Bruce Momjian wrote:
Those who have been with the community from long ago might remember
discussion about implementing a undo log. The big advantage of this is
that it allows UPDATE to _replace_ rows and limits the amount of cleanup
required for UPDATEs.
I am hoping that with HOT we will no lon
12 matches
Mail list logo
