Abhijit Menon-Sen wrote:
At 2008-08-25 10:24:01 +0300, [EMAIL PROTECTED] wrote:
My original plan was to enable index-only-scans using the DSM as well
for 8.4, but it's pretty clear at this point that I don't have the
time to finish that :-(.
I wonder how hard that would be.
It's doable, for
Tom Lane wrote:
[ off-list ]
Matthew T. O'Connor [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm not sure how important it will really be once we have support for
dead-space-map-driven vacuum.
Is that something we can expect any time soon? I haven't heard much
about it really happening for
On Fri, Aug 22, 2008 at 11:36 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
I assume there is no TODO here.
Well, there doesn't seem to be a TODO for partial/restartable vacuums,
which were mentioned upthread. This is a really desirable feature for
big databases and removes one of the reasons to
Merlin Moncure wrote:
On Fri, Aug 22, 2008 at 11:36 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
I assume there is no TODO here.
Well, there doesn't seem to be a TODO for partial/restartable vacuums,
which were mentioned upthread. This is a really desirable feature for
big databases and
Joshua D. Drake wrote:
Merlin Moncure wrote:
Well, there doesn't seem to be a TODO for partial/restartable vacuums,
which were mentioned upthread. This is a really desirable feature for
big databases and removes one of the reasons to partition large
tables.
I would agree that partial vacuums
Matthew T. O'Connor [EMAIL PROTECTED] writes:
I think everyone agrees that partial vacuums would be useful / *A Good
Thing* but it's the implementation that is the issue.
I'm not sure how important it will really be once we have support for
dead-space-map-driven vacuum.
Tom Lane wrote:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
I think everyone agrees that partial vacuums would be useful / *A Good
Thing* but it's the implementation that is the issue.
I'm not sure how important it will really be once we have support for
dead-space-map-driven
I assume there is no TODO here.
---
Pavan Deolasee wrote:
(taking the discussions to -hackers)
On Sat, Jul 12, 2008 at 11:02 PM, Tom Lane [EMAIL PROTECTED] wrote:
(2) It achieves speedup of VACUUM by pushing work
Gregory Stark wrote:
I thought
we only pruned when we wanted to insert a new tuple and found not enough
space.
Nope, we prune on any access to the page, if the page is full enough,
and the pd_prune_xid field suggests that there is something to prune.
The problem with only pruning on inserts
Pavan Deolasee [EMAIL PROTECTED] writes:
(taking the discussions to -hackers)
On Sat, Jul 12, 2008 at 11:02 PM, Tom Lane [EMAIL PROTECTED] wrote:
(2) It achieves speedup of VACUUM by pushing work onto subsequent
regular accesses of the page, which is exactly the wrong thing.
Worse, once you
Tom Lane [EMAIL PROTECTED] writes:
It strikes me that what you are trying to do here is compensate for
a bad decision in the HOT patch, which was to have VACUUM's first
pass prune/defrag a page even when we know we are going to have to
come back to that page later. What about trying to fix
Gregory Stark [EMAIL PROTECTED] writes:
I like the idea of only having to do a single pass through the table though.
Well, that argument was already overstated: we're not re-reading all of
the table now. Just the pages containing dead line pointers.
Couldn't Pavan's original plan still work
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
I like the idea of only having to do a single pass through the table though.
Well, that argument was already overstated: we're not re-reading all of
the table now. Just the pages containing dead line pointers.
(taking the discussions to -hackers)
On Sat, Jul 12, 2008 at 11:02 PM, Tom Lane [EMAIL PROTECTED] wrote:
(2) It achieves speedup of VACUUM by pushing work onto subsequent
regular accesses of the page, which is exactly the wrong thing.
Worse, once you count the disk writes those accesses will
14 matches
Mail list logo