On Tue, 2007-09-11 at 09:21 +0530, Pavan Deolasee wrote:
> IMHO we are making full circles here. We have already tried LP_DELETE
> techniques and moved away to simplify things.
> We can save rest of the techniques for beta testing period or 8.4.
Agreed, we're just fine tuning by reinventing old
On Mon, 2007-09-10 at 22:24 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Tue, 2007-09-11 at 01:22 +0530, Pavan Deolasee wrote:
> >> I think the only difference is that the quick pruning does not mark
> >> intermediate tuples ~LP_USED and hence we may avoid WAL logging.
>
Pavan Deolasee wrote:
> IMHO we are making full circles here. We have already tried LP_DELETE
> techniques
> and moved away to simplify things. We also tried reusing dead space without
> running PageRepairFragmentation. Each of these techniques worked just fine
> with slightly different performance
On 9/11/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
>
>
>
>
> You could mark such tuples with LP_DELETE. That would also let other
> transactions quickly tot up how much space would be available if they were
> to
> run PageRepairFragmentation.
>
>
>
>
IMHO we are making full circles here. We have
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Tue, 2007-09-11 at 01:22 +0530, Pavan Deolasee wrote:
> >> I think the only difference is that the quick pruning does not mark
> >> intermediate tuples ~LP_USED and hence we may avoid WAL logging.
>
> > Sounds great.
>
> What it sou
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2007-09-11 at 01:22 +0530, Pavan Deolasee wrote:
>> I think the only difference is that the quick pruning does not mark
>> intermediate tuples ~LP_USED and hence we may avoid WAL logging.
> Sounds great.
What it sounds is utterly unsafe. You can
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> Pruning removes intermediate dead tuples by marking their line pointers
> ~LP_USED and redirecting the root line pointer to the first
> live/recently_dead tuple in the chain.
It seems utterly unsafe to do this without a vacuum-grade lock on the
page.
Teodor Sigaev wrote:
> Heikki Linnakangas wrote:
>> * Defined new struct WordEntryPosVector that holds a uint16 length and a
>> variable size array of WordEntries. This replaces the previous
>> convention of a variable size uint16 array, with the first element
>> implying the length. WordEntryPosVe
Heikki Linnakangas wrote:
* Defined new struct WordEntryPosVector that holds a uint16 length and a
variable size array of WordEntries. This replaces the previous
convention of a variable size uint16 array, with the first element
implying the length. WordEntryPosVector has the same layout in mem
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On 9/11/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
>> Right. My point is that pruning only modifies item pointers. It does
>> not change the actual heap tuples. In the quote above, how is Heikki's
>> "quick pruning" different from the pruning
On Tue, 2007-09-11 at 01:22 +0530, Pavan Deolasee wrote:
> I think the only difference is that the quick pruning does not mark
> intermediate tuples ~LP_USED and hence we may avoid WAL logging.
Sounds great.
> Btw, I am not too enthusiastic about quick pruning because it leaves
> behind dead he
I tried to compile a custom tsearch dictionary as an external module,
but it couldn't find the tsearch include files in the server
installation. tsearch subdirectory needs to be added to
src/include/Makefile, otherwise they don't get installed:
*** src/include/Makefile9 Dec 2005 21:19:35 -
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > Looking at the patch I see:
> >
> > + /*
> > +* Mark the page as clear of prunable tuples. If we find a tuple
> > which
> > +* may become prunable, we shall set the hint again.
> > +*/
> > +
On Mon, 2007-09-10 at 20:46 +0100, Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > Pavan Deolasee wrote:
> >> At the end of pruning:
> >>
> >> - line pointer of 1 is redirected to 4
> >> - line pointers of 2 and 3 are marked ~LP_USED
> >> - the offset of 4 and 5 is unchanged
> >>
> > In the q
On 9/11/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
>
>
> Right. My point is that pruning only modifies item pointers. It does
> not change the actual heap tuples. In the quote above, how is Heikki's
> "quick pruning" different from the pruning you are describing?
>
>
>
I think the only diffe
Bruce Momjian wrote:
> Pavan Deolasee wrote:
Pruning does generate a WAL record at the moment. Maybe you could do
some kind of a quick pruning without a WAL record. Like just modify the
ctid of the oldest dead tuple in the chain, or the redirecting line
pointer if there is one,
Pavan Deolasee wrote:
> > > Pruning does generate a WAL record at the moment. Maybe you could do
> > > some kind of a quick pruning without a WAL record. Like just modify the
> > > ctid of the oldest dead tuple in the chain, or the redirecting line
> > > pointer if there is one, to point to the lat
Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > My guess is that once you prune a tuple
> > you no longer have to check its visibility, and that is where the win is
> > coming from.
>
> Yes, I think that's right.
>
> Oh, one more thing occured to me. Without HOT, we not only mark index
> t
On 9/11/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> Heikki Linnakangas wrote:
>
> >
> > Pruning does generate a WAL record at the moment. Maybe you could do
> > some kind of a quick pruning without a WAL record. Like just modify the
> > ctid of the oldest dead tuple in the chain, or the redire
On 9/10/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>
>
> Oh, one more thing occured to me. Without HOT, we not only mark index
> tuples pointing to dead tuples as killed, we remove them altogether if
> the index page gets full. If you modify the test case so that after
> doing the updates, y
On 9/10/07, Florian Pflug <[EMAIL PROTECTED]> wrote:
>
>
> Maybe that risk could be lowered if instead of a flag, we stored the
> minimal global xmin needed to prune at least one tuple.
>
>
I like the idea. The question is whether the chances of a Prunable
page being looked up again and again in p
On Mon, 2007-09-10 at 18:23 +0100, Heikki Linnakangas wrote:
> > If we check a tuple in a chain and the tuple is dead is it possible the
> > pruning operation is cheaper than having to check the tuple again for
> > visibility the next time we see it? If so, we can just always prune
> > when we se
Bruce Momjian wrote:
Looking at the patch I see:
+ /*
+* Mark the page as clear of prunable tuples. If we find a tuple which
+* may become prunable, we shall set the hint again.
+*/
+ PageClearPrunable(page);
I like the idea of the page hint bit, but my quest
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Looking at the patch I see:
>
> + /*
> +* Mark the page as clear of prunable tuples. If we find a tuple which
> +* may become prunable, we shall set the hint again.
> +*/
> + PageClearPrunable(page);
>
> I like the i
Pavan Deolasee wrote:
> Until patch version 14, defragmentation and pruning were separate
> operations, though we used to invoke both at the same time. The only
> difference was that pruning can work with a simple exclusive lock
> whereas defragmentation needs vacuum-strength lock. Tom argued
> tha
Bruce Momjian wrote:
> My guess is that once you prune a tuple
> you no longer have to check its visibility, and that is where the win is
> coming from.
Yes, I think that's right.
Oh, one more thing occured to me. Without HOT, we not only mark index
tuples pointing to dead tuples as killed, we
Heikki Linnakangas wrote:
> HEADHOT HOT-opt HOT-pruned
> seqscan 19.921.120.111.5
> idxscan 27.831.430.413.7
>
> Explanations of the columns:
>
> HEAD: CVS HEAD
> HOT-pruned: CVS HEAD + HOT patch v15
> HOT:
* Defined new struct WordEntryPosVector that holds a uint16 length and a
variable size array of WordEntries. This replaces the previous
convention of a variable size uint16 array, with the first element
implying the length. WordEntryPosVector has the same layout in memory,
but is more readable in s
On Mon, 2007-09-10 at 10:21 -0400, Tom Lane wrote:
> Oleg Bartunov <[EMAIL PROTECTED]> writes:
> > On Mon, 10 Sep 2007, Simon Riggs wrote:
> >> Can we include that functionality now?
>
> > This could be realized very easyly using dict_strict, which returns
> > only known words, and mapping contain
On 9/10/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2007-09-10 at 12:17 +0100, Heikki Linnakangas wrote:
> > Bruce Momjian wrote:
> > > (Can someone time the access time for following a chain that fills an
> > > entire page (the worst case) vs. having a single tuple on the page?)
> >
> >
On 9/8/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
>
>
> Would someone tell us exactly when pruning and defragmenting happens in
> the current version of the patch? If we don't nail this issue down soon
> PostgreSQL 8.3 is going to sail without this patch.
>
>
>
I guess you already have the an
On Mon, 2007-09-10 at 12:17 +0100, Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > (Can someone time the access time for following a chain that fills an
> > entire page (the worst case) vs. having a single tuple on the page?)
>
> Here is some results, on my laptop.
> HEADH
On 9/6/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> > When I suggested that we get rid of the LP_DELETE flag for heap tuples,
> > the tuple-level fragmentation and all that, and just take the vacuum
> > lock and call PageRepairFragmentation, I was t
Heikki Linnakangas wrote:
> Explanations of the columns:
>
> HEAD: CVS HEAD
> HOT-pruned: CVS HEAD + HOT patch v15
> HOT: CVS HEAD + HOT patch v15, but with heap_page_prune_defrag short
> circuited to do nothing
> HOT-opt: CVS HEAD + HOT patch v15, but with static XidInMVCC
Bruce Momjian wrote:
> (Can someone time the access time for following a chain that fills an
> entire page (the worst case) vs. having a single tuple on the page?)
Here is some results, on my laptop. The test case is a table with a
single integer column, and a single row in the table. The row is u
On 9/10/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>
>
>
> I'm repeating myself, but I would split that second operation into two
> parts while we think about this: pruning the entire page, and
> defragmenting (PageRepairFragmentation). Tom wondered why they're
> separated in the patch. As t
Bruce Momjian wrote:
> Tom Lane wrote:
>> The we-already-pinned-the-page problem is a bit nasty but may not be
>> insurmountable.
If you find a way, that would be great.
> As I understand it, there are two HOT features:
>
> Single-chain pruning, which trims HOT chains but doesn't reuse
>
On Mon, 2007-09-10 at 09:03 +0100, Heikki Linnakangas wrote:
> > As I understand it, there are two HOT features:
> >
> > Single-chain pruning, which trims HOT chains but doesn't reuse
> > the space
> >
> > Defragementation, which prunes the entire page and reuses space
> >
38 matches
Mail list logo
