On Thu, 22 Dec 2005 10:40:24 -0500, Tom Lane [EMAIL PROTECTED]
wrote:
If you move items
from one page to the other in the opposite direction from the way the
scan is going, then it will miss those items.
AFAIU the (PG implementaion of the) LY method is designed to make
scans immune against
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
We already do something similar for page deletions. Empty pages are not
deleted right away, but they are marked with BTP_DEAD, and then deleted
on a subsequent vacuum. Or something like that, I don't remember the
exact details.
Manfred Koizar [EMAIL PROTECTED] writes:
BTW, if after having locked both pages we find that we have
super-exclusive locks, i.e. nobody else has pins on these pages, we
can reorganize much more agressively.
No, we cannot. I'm getting tired of explaining this.
regards,
Kevin Brown [EMAIL PROTECTED] writes:
Well, REINDEX is apparently a very expensive operation right now. But
how expensive would it be to go through the entire index and perform
the index page merge operation being discussed here, and nothing else?
If it's fast enough, might it be worthwhile
On Wed, 2005-12-21 at 19:07 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
While we scan, if we found two adjacent pages, both of which have less
than (say) 40% rows, we could re-join or unsplit those pages together.
Curiously enough, this has been thought of before. It is
Simon Riggs [EMAIL PROTECTED] writes:
Sorry, I missed that.
And you evidently still didn't understand it. Locking both pages does
not fix the problem, because it doesn't guarantee that there's not a
concurrent indexscan in flight from one to the other. If you move items
from one page to the
On Thu, Dec 22, 2005 at 10:40:24AM -0500, Tom Lane wrote:
And you evidently still didn't understand it. Locking both pages does
not fix the problem, because it doesn't guarantee that there's not a
concurrent indexscan in flight from one to the other. If you move items
from one page to the
Martijn van Oosterhout wrote:
The downsides are probably that it's a pain to make it work
concurrently and requires writing each index page at least twice. But
it's a thought...
We already do something similar for page deletions. Empty pages are not
deleted right away, but they are marked
Alvaro Herrera [EMAIL PROTECTED] writes:
We already do something similar for page deletions. Empty pages are not
deleted right away, but they are marked with BTP_DEAD, and then deleted
on a subsequent vacuum. Or something like that, I don't remember the
exact details.
Right, and the reason
On Thu, 2005-12-22 at 10:40 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Sorry, I missed that.
And you evidently still didn't understand it. Locking both pages does
not fix the problem, because it doesn't guarantee that there's not a
concurrent indexscan in flight from
When we discussed online REINDEX recently we focused on the REINDEX
command itself rather than look at alternative approaches.
One reason to REINDEX is because of index page splits getting things out
of sequence and generally bloating the index.
When we VACUUM, each index is scanned in logical
Simon Riggs [EMAIL PROTECTED] writes:
While we scan, if we found two adjacent pages, both of which have less
than (say) 40% rows, we could re-join or unsplit those pages together.
Curiously enough, this has been thought of before. It is not as easy
as you think, or it would have been done the
12 matches
Mail list logo
