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 of an open issue
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 attributes
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 aborted
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
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
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 is
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
the dead
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 would
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 whether
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/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 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 the
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
remove it
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 outcome. If
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 index, we should
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, HOT
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 this, you
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 worst
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 we want to
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 on
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
important things
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 conclusion
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
line
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 pointers take
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 statio
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 before
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 not
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.
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 not
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 that
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
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
important
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 suggest we simply
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 before
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 overflow, since we
35 matches
Mail list logo
