On Friday 10 November 2006 08:53, Simon Riggs wrote:
> On Fri, 2006-11-10 at 12:32 +0100, Zeugswetter Andreas ADI SD wrote:
> > 4. although at first it might seem so I see no advantage for vacuum with
> > overflow
>
> No need to VACUUM the indexes, which is the most expensive part. The
> more index
On Fri, 2006-11-10 at 16:46 +0100, Zeugswetter Andreas ADI SD wrote:
> > I'm not sure this really solves that problem because there
> > are still DELETEs to consider but it does remove one factor
> > that exacerbates it unnecessarily.
>
> Yea, so you still need to vaccum the large table regular
Hi,
On 11/10/06, Zeugswetter Andreas ADI SD <[EMAIL PROTECTED]> wrote:
> > True, but Nikhil has run tests that clearly show HOT outperforming> > current situation in the case of long running transactions. The need
> > to optimise HeapTupleSatisfiesVacuum() and avoid long chains does> > still remain
> > True, but Nikhil has run tests that clearly show HOT outperforming
> > current situation in the case of long running transactions. The need
> > to optimise HeapTupleSatisfiesVacuum() and avoid long chains does
> > still remain a difficulty for both HOT and the current situation.
>
>
> Yes
> > 2. locking should be easier if only the original heap page is
involved.
>
> Yes, but multi-page update already happens now, so HOT is not
> different on that point.
I was thinking about the case when you "pull back" a tuple, which seems
to be more
difficult than what we have now.
Andreas
Hi,
> True, but Nikhil has run tests that clearly show HOT outperforming
> current situation in the case of long running transactions. The need to
> optimise HeapTupleSatisfiesVacuum() and avoid long chains does still
> remain a difficulty for both HOT and the current situation.
>
Yes, I carried
On 11/10/06, Simon Riggs <[EMAIL PROTECTED]> wrote:
On Fri, 2006-11-10 at 12:32 +0100, Zeugswetter Andreas ADI SD wrote:> e.g. a different header seems no easier in overflow than in heap
True. The idea there is that we can turn frequent update on/off fairlyeasily for normal tables since there are n
On Fri, 2006-11-10 at 12:32 +0100, Zeugswetter Andreas ADI SD wrote:
> > > As more UPDATEs take place these tuple chains would grow, making
> > > locating the latest tuple take progressively longer.
>
> > More generally, do we need an overflow table at all, rather
> > than having these overflow
Hi,
> > This allows the length of a typical tuple chain to be extremely short in> > practice. For a single connection issuing a stream of UPDATEs the chain> > length will no more than 1 at any time.
>> Only if there are no other transactions being held open, which makes> this claim a lot weaker.T
"Simon Riggs" <[EMAIL PROTECTED]> writes:
>> Seems like "altering the row length" isn't the issue, it's just "is
>> there room on the page for the new version". Again, a generous
>> fillfactor would give you more flexibility.
>
> The copy-back operation can only work if the tuple fits in the same
Oops, pressed send too early. Ignore the one-line reply I just sent...
Simon Riggs wrote:
On Thu, 2006-11-09 at 18:28 -0500, Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
HOT can only work in cases where a tuple does not modify one of the
columns defined in an index on the table, a
Simon Riggs wrote:
On Thu, 2006-11-09 at 18:28 -0500, Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
HOT can only work in cases where a tuple does not modify one of the
columns defined in an index on the table, and when we do not alter the
row length of the tuple.
Seems like "alteri
On Thu, 2006-11-09 at 18:28 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > As more UPDATEs take place these tuple chains would grow, making
> > locating the latest tuple take progressively longer.
>
> This is the part that bothers me --- particularly the random-access
> nat
On Thu, 2006-11-09 at 13:21 -0800, Josh Berkus wrote:
> Simon,
>
> > If we perform an update that meets the HOT criteria then we put the
> > new version into the overflow relation; we describe this as a HOT
> > UPDATE. If we perform an update that does not meet the criteria, then we
> > carry on w
On Thu, 2006-11-09 at 18:49 +0100, Martijn van Oosterhout wrote:
> Nice idea, just one question:
> It seems to me that bitmap index scans will get these same
> characteristics also, right? The bitmap scan will have to follow the
> chain of any possibly matching tuple in any of the blocks that are
15 matches
Mail list logo
