On 8/14/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
>
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> >
> > Doesn't this design completely fail to take index bloat into account?
> > Repairing heap fragmentation does not reduce the need for VACUUM to work
> > on the indexes.
>
> Index bloat is a bit o
On Tue, 2007-08-14 at 10:10 -0400, Tom Lane wrote:
> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> > What if we just track the amount of potentially dead space in the
> > relation
> > (somebody had suggested that earlier in the thread) ? Every committed
> > UPDATE/DELETE and aborted UPDATE/INSERT
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
>> What if we just track the amount of potentially dead space in the
>> relation
>> (somebody had suggested that earlier in the thread) ? Every committed
>> UPDATE/DELETE and aborted UPDATE/INSERT would increment
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> What if we just track the amount of potentially dead space in the
> relation
> (somebody had suggested that earlier in the thread) ? Every committed
> UPDATE/DELETE and aborted UPDATE/INSERT would increment
> the dead space. Whenever page fragmentation
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> I am trying to figure out the best way to extract this information. Is there
> any
> existing code to get all attributes used in the expressions ? Or do I need
> to walk the tree and extract that information ?
There are a number of near matches in bac
On Tue, 2007-08-14 at 13:24 +0530, Pavan Deolasee wrote:
>
>
> On 8/9/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-08-09 at 15:46 +0530, Pavan Deolasee wrote:
> >
>
> > What if we just track the amount of potentially dead space
> in the
>
On 8/9/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2007-08-09 at 15:46 +0530, Pavan Deolasee wrote:
> >
>
> > What if we just track the amount of potentially dead space in the
> > relation
> > (somebody had suggested that earlier in the thread) ? Every committed
> > UPDATE/DELETE and abo
On 8/9/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>
>
>
> Yeah, we could simply insist on no change to any column that's used by
> any of the expressions. That would be cheap to test.
>
>
>
I am trying to figure out the best way to extract this information. Is there
any
existing code to get all attri
Gregory Stark <[EMAIL PROTECTED]> writes:
> I agree about the costs for evaluating the expressions. But a COLD update is
> certainly going to have to evaluate both expressions once. The only additional
> cost here is that HOT is going to have to evaluate the *old* expression as
> well. So it's at w
"Tom Lane" <[EMAIL PROTECTED]> writes:
> We have so far managed to avoid any really strong dependencies on the
> requirement of index-function immutability --- your queries may not work
> very well if the function isn't immutable, but you are not at risk of
> system-level data corruption. With thi
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> I started with this. ISTM to support partial indexes, we must check
> the old and new tuple against partiality match.
> ...
> For functional index, we should apply the function to the old and new
> tuple and compare the outcome. If the results are same
On Thu, Aug 09, 2007 at 01:25:14PM +0100, Gregory Stark wrote:
> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
>
> > HOT update is feasible iff
> >
> > - old and new tuples, both match the partiality condition OR
> > - old and new tuples, both don't match the condition
> ...
> > For functional inde
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> HOT update is feasible iff
>
> - old and new tuples, both match the partiality condition OR
> - old and new tuples, both don't match the condition
...
> For functional index, we should apply the function to the old and new
> tuple and compare the outc
On Thu, 2007-08-09 at 15:46 +0530, Pavan Deolasee wrote:
>
>
> On 8/9/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> Whether I got the exact details of frugging & depruning
> correct or not:
> if a tuple version is removed, then VACUUM doesn't need to
> re
On 8/9/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
>
> Whether I got the exact details of frugging & depruning correct or not:
> if a tuple version is removed, then VACUUM doesn't need to remove it
> later, so any non-VACUUM removal of rows must defer a VACUUM.
>
>
ISTM that you are worried about
On 8/7/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>
> There's three things clearly missing in the patch:
>
> 1. HOT updates on tables with expression or partial indexes. Hasn't been
> done yet because it should be pretty straightforward and we've had more
> important things to do. Though not
On Thu, 2007-08-09 at 12:39 +0530, Pavan Deolasee wrote:
> No, pruning removes all dead tuples, irrespective of whether they are
> HOT or COLD updated and whether they are heap-only or not. It
> handles line pointer redirection and marks
> all dead tuples as ~LP_USED. Defragging just repairs the
On 8/8/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
>
>
> So pruning removes dead hot updated tuples, while defragging will remove
> dead cold updated tuples and deletes, as well as rearranging space.
No, pruning removes all dead tuples, irrespective of whether they are
HOT or COLD updated and w
On Wed, 2007-08-08 at 09:55 +0100, Heikki Linnakangas wrote:
> >> 3. Statistics and autovacuum integration. How should HOT updates be
> >> taken into account when deciding when to autovacuum and autoanalyze?
> >> There's a FIXME comment in analyze.c related to this as well. What
> >> additional st
On Wed, Aug 08, 2007 at 04:45:44PM +0530, Pavan Deolasee wrote:
> On 8/8/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
> > It seems that previously percentage of tuples made sense because dead
> > tuples
> > took about the same amount of space as new tuples that need that space.
> > But
> > line poi
On 8/8/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
>
>
>
> It seems that previously percentage of tuples made sense because dead
> tuples
> took about the same amount of space as new tuples that need that space.
> But
> line pointers take much less space than the new tuples so the number of
> dead
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Because we can truncate dead tuples, even from cold updates and deletes,
> to redirected dead line pointers which take much less space than dead
> tuples, maybe we should increase the default autovacuum threshold?
That would be the logical concl
Simon Riggs wrote:
> On Tue, 2007-08-07 at 19:01 +0100, Heikki Linnakangas wrote:
>> There's three things clearly missing in the patch:
>>
>> 1. HOT updates on tables with expression or partial indexes. Hasn't been
>> done yet because it should be pretty straightforward and we've had more
>> import
On 8/7/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>
> There's three things clearly missing in the patch:
Yes, these are the major ones, though we might want to play with
the chain pruning, FSM handling and other smaller things to see
if there are any performance benefits.
1. HOT updates
Mark Mielke wrote:
> Stefan Kaltenbrunner wrote:
>> Heikki Linnakangas wrote:
>>
>>> 2. Pointer swinging. At the moment, after a row is HOT updated, the only
>>> way to get rid of the redirecting line pointer is to run VACUUM FULL or
>>> CLUSTER (or delete or cold update the row and vacuum). If w
On Tue, 2007-08-07 at 16:52 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Tue, 2007-08-07 at 15:14 -0400, Tom Lane wrote:
> >> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> >>> We also need something that will re-zero the stats when they reach
> >>> anywhere near integer o
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> 2. Pointer swinging. At the moment, after a row is HOT updated, the only
> way to get rid of the redirecting line pointer is to run VACUUM FULL or
> CLUSTER (or delete or cold update the row and vacuum). If we want to
> implement pointer swinging
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Tue, 2007-08-07 at 15:14 -0400, Tom Lane wrote:
>> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>>> We also need something that will re-zero the stats when they reach
>>> anywhere near integer overflow, since we must not allow them to wrap. I
>>> would su
Heikki Linnakangas wrote:
> Stefan Kaltenbrunner wrote:
>> Heikki Linnakangas wrote:
>>> There's three things clearly missing in the patch:
>>>
>>> 1. HOT updates on tables with expression or partial indexes. Hasn't been
>>> done yet because it should be pretty straightforward and we've had more
>>
Stefan Kaltenbrunner wrote:
Heikki Linnakangas wrote:
2. Pointer swinging. At the moment, after a row is HOT updated, the only
way to get rid of the redirecting line pointer is to run VACUUM FULL or
CLUSTER (or delete or cold update the row and vacuum). If we want to
implement pointer swingin
On Tue, 2007-08-07 at 15:14 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > We also need something that will re-zero the stats when they reach
> > anywhere near integer overflow, since we must not allow them to wrap. I
> > would suggest we simply reset all values to zero for
Stefan Kaltenbrunner wrote:
> Heikki Linnakangas wrote:
>> There's three things clearly missing in the patch:
>>
>> 1. HOT updates on tables with expression or partial indexes. Hasn't been
>> done yet because it should be pretty straightforward and we've had more
>> important things to do. Though n
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> We also need something that will re-zero the stats when they reach
> anywhere near integer overflow, since we must not allow them to wrap. I
> would suggest we simply reset all values to zero for that table.
pgstat counters are int64.
On Tue, 2007-08-07 at 19:01 +0100, Heikki Linnakangas wrote:
> There's three things clearly missing in the patch:
>
> 1. HOT updates on tables with expression or partial indexes. Hasn't been
> done yet because it should be pretty straightforward and we've had more
> important things to do. Though
Heikki Linnakangas wrote:
> There's three things clearly missing in the patch:
>
> 1. HOT updates on tables with expression or partial indexes. Hasn't been
> done yet because it should be pretty straightforward and we've had more
> important things to do. Though not critical, should be finished be
There's three things clearly missing in the patch:
1. HOT updates on tables with expression or partial indexes. Hasn't been
done yet because it should be pretty straightforward and we've had more
important things to do. Though not critical, should be finished before
release in my opinion.
2. Poin
36 matches
Mail list logo
