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 fo
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 vac
"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.
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 wo
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 remov
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
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 pus
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 insert
"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 point
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 wor
"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
"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.
>> Wors
(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 accesse
14 matches
Mail list logo
