There's a fair amount of added work to be done when updating tuples.
Will it be possible to postpone some of that to the bgwriter in a later
version? I realize that sometimes you'll still want to do the work up
front, like if it means we can stay on the same page instead of going
cold...
On Tue, F
On Tue, 2007-02-20 at 09:48 +0200, Hannu Krosing wrote:
> I'm not sure about the "we are more concerned about the large tables"
> part. I see it more as a device for high-update tables. This may not
> always be the same as "large", so there should be some fallbacks for
> case where you can't get t
On Tue, Feb 20, 2007 at 08:31:45PM +0530, Pavan Deolasee wrote:
> I see your point, but as you mentioned do we really care ? The chain
> needs to be broken so that the intermediate DEAD tuples can be
> vacuumed. We can't vacuum them normally because they could
> be a part of live HOT-update chain.
On 2/20/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Tom Lane wrote:
>
> "Recently dead" means "still live to somebody", so those tids better not
> change either. But I don't think that's what he meant. I'm more
> worried about the deadlock possibilities inherent in trying to upgrade a
> buffe
On 2/20/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> ... Yes. The HOT-updated status of the root and all intermediate
> tuples is cleared and their respective ctid pointers are made
> point to themselves.
Doesn't that destroy the knowledge that they for
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Pavan Deolasee wrote:
> >> When following a HOT-update chain from the index fetch, if we notice that
> >> the root tuple is dead and it is HOT-updated, we try to prune the chain to
> >> the smallest possible length. To do that, the sha
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Pavan Deolasee wrote:
>> When following a HOT-update chain from the index fetch, if we notice that
>> the root tuple is dead and it is HOT-updated, we try to prune the chain to
>> the smallest possible length. To do that, the share lock is upgraded to an
Pavan Deolasee wrote:
> On 2/20/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> > Pavan Deolasee wrote:
> > > When following a HOT-update chain from the index fetch, if we notice
> > that
> > > the root tuple is dead and it is HOT-updated, we try to prune the chain
> > to
> > > the smallest poss
On 2/20/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Pavan Deolasee wrote:
> When following a HOT-update chain from the index fetch, if we notice
that
> the root tuple is dead and it is HOT-updated, we try to prune the chain
to
> the smallest possible length. To do that, the share lock is upgrad
Pavan Deolasee wrote:
> When following a HOT-update chain from the index fetch, if we notice that
> the root tuple is dead and it is HOT-updated, we try to prune the chain to
> the smallest possible length. To do that, the share lock is upgraded to an
> exclusive lock and the tuple chain is followe
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> ... Yes. The HOT-updated status of the root and all intermediate
> tuples is cleared and their respective ctid pointers are made
> point to themselves.
Doesn't that destroy the knowledge that they form a tuple chain?
While it might be that no one care
On 2/20/07, Hannu Krosing <[EMAIL PROTECTED]> wrote:
Ühel kenal päeval, T, 2007-02-20 kell 12:08, kirjutas Pavan Deolasee:
What do you do, if there are no live tuples on the page ? will this
un-HOTify the root and free all other tuples in HOT chain ?
Yes. The HOT-updated status of the root
Ühel kenal päeval, T, 2007-02-20 kell 12:08, kirjutas Pavan Deolasee:
>
> Reposting - looks like the message did not get through in the first
> attempt. My apologies if multiple copies are received.
>
>
> This is the next version of the HOT WIP patch. Since the last patch
> that
> I sent out, I
Reposting - looks like the message did not get through in the first
attempt. My apologies if multiple copies are received.
This is the next version of the HOT WIP patch. Since the last patch that
I sent out, I have implemented the HOT-update chain pruning mechanism.
When following a HOT-update
14 matches
Mail list logo
