On 02/16/2014 10:19 PM, Jim Nasby wrote:
On 1/24/14, 3:52 PM, Jaime Casanova wrote:
On Tue, Dec 3, 2013 at 11:25 AM, Bruce Momjian wrote:
Is everyone else OK with this approach? Updated patch attached.
Hi,
I started to look at this patch and i found that it fails an assertion
as soon as y
On 1/24/14, 3:52 PM, Jaime Casanova wrote:
On Tue, Dec 3, 2013 at 11:25 AM, Bruce Momjian wrote:
>
>Is everyone else OK with this approach? Updated patch attached.
>
Hi,
I started to look at this patch and i found that it fails an assertion
as soon as you run a VACUUM FULL after a lazy VACUU
On 2014-02-15 21:34:15 -0500, Bruce Momjian wrote:
> Thank you for the thorough review. Unless someone else can complete
> this, I think it should be marked as returned with feedback. I don't
> think I am going to learn enough to complete this during the
> commit-fest.
Agreed. Marked it as such.
On Sat, Feb 15, 2014 at 07:08:40PM +0100, Andres Freund wrote:
> > Can you be more specific about the cluster.c idea? I see
> > copy_heap_data() in cluster.c calling HeapTupleSatisfiesVacuum() with a
> > 'buf' just like the code I am working in.
>
> Yes, it does. But in contrast to your patch it
On 2014-02-15 12:50:14 -0500, Bruce Momjian wrote:
> On Sat, Feb 15, 2014 at 04:16:40PM +0100, Andres Freund wrote:
> > Hi,
> >
> > > *** end_heap_rewrite(RewriteState state)
> > > *** 281,286
> > > --- 284,290
> > > true);
>
On Sat, Feb 15, 2014 at 04:16:40PM +0100, Andres Freund wrote:
> Hi,
>
> > *** end_heap_rewrite(RewriteState state)
> > *** 281,286
> > --- 284,290
> > true);
> > RelationOpenSmgr(state->rs_new_rel);
> >
> > +
Hi,
> *** end_heap_rewrite(RewriteState state)
> *** 281,286
> --- 284,290
> true);
> RelationOpenSmgr(state->rs_new_rel);
>
> + update_page_vm(state->rs_new_rel, state->rs_buffer,
> state->rs_blockno
On Fri, Jan 24, 2014 at 04:52:55PM -0500, Jaime Casanova wrote:
> On Tue, Dec 3, 2013 at 11:25 AM, Bruce Momjian wrote:
> >
> > Is everyone else OK with this approach? Updated patch attached.
> >
>
> Hi,
>
> I started to look at this patch and i found that it fails an assertion
> as soon as you
On Tue, Dec 3, 2013 at 11:25 AM, Bruce Momjian wrote:
>
> Is everyone else OK with this approach? Updated patch attached.
>
Hi,
I started to look at this patch and i found that it fails an assertion
as soon as you run a VACUUM FULL after a lazy VACUUM even if those are
on unrelated relations. F
On 28 November 2013 22:17, Robert Haas wrote:
> The fact that you've needed to modify SetHintBits() to make this work
> is pretty nasty. I'm not exactly sure what to do about that, but it
> doesn't seem good.
That makes me feel bad also.
I think we should be looking for some special case routi
On Tue, Dec 3, 2013 at 02:01:52PM -0500, Robert Haas wrote:
> On Tue, Dec 3, 2013 at 11:25 AM, Bruce Momjian wrote:
> > On Thu, Nov 28, 2013 at 05:38:05PM -0500, Bruce Momjian wrote:
> >> > I wonder if we ought to mark each page as all-visible in
> >> > raw_heap_insert() when we first initialize
On Tue, Dec 3, 2013 at 11:25 AM, Bruce Momjian wrote:
> On Thu, Nov 28, 2013 at 05:38:05PM -0500, Bruce Momjian wrote:
>> > I wonder if we ought to mark each page as all-visible in
>> > raw_heap_insert() when we first initialize it, and then clear the flag
>> > when we come across a tuple that isn
On Thu, Nov 28, 2013 at 05:38:05PM -0500, Bruce Momjian wrote:
> > I wonder if we ought to mark each page as all-visible in
> > raw_heap_insert() when we first initialize it, and then clear the flag
> > when we come across a tuple that isn't all-visible. We could try to
> > set hint bits on the tu
On Thu, Nov 28, 2013 at 05:17:07PM -0500, Robert Haas wrote:
> > I need to know this is the right approach, and need to know what things
> > are wrong or missing.
>
> The fact that you've needed to modify SetHintBits() to make this work
> is pretty nasty. I'm not exactly sure what to do about tha
On Wed, Nov 27, 2013 at 4:33 PM, Bruce Momjian wrote:
> On Sat, Jan 12, 2013 at 02:14:03PM -0500, Kevin Grittner wrote:
>> Amit Kapila wrote:
>> > On Thursday, January 10, 2013 6:09 AM Josh Berkus wrote:
>>
>> >> Surely VACUUM FULL should rebuild the visibility map, and make
>> >> tuples in the ne
On Sat, Jan 12, 2013 at 02:14:03PM -0500, Kevin Grittner wrote:
> Amit Kapila wrote:
> > On Thursday, January 10, 2013 6:09 AM Josh Berkus wrote:
>
> >> Surely VACUUM FULL should rebuild the visibility map, and make
> >> tuples in the new relation all-visible, no?
>
> Certainly it seems odd to me
Amit Kapila wrote:
> On Thursday, January 10, 2013 6:09 AM Josh Berkus wrote:
>> Surely VACUUM FULL should rebuild the visibility map, and make
>> tuples in the new relation all-visible, no?
Certainly it seems odd to me that VACUUM FULL leaves the the table
in a less-well maintained state in term
On Thursday, January 10, 2013 12:01 PM Pavan Deolasee wrote:
> On Thu, Jan 10, 2013 at 11:45 AM, Amit Kapila
> wrote:
> > On Thursday, January 10, 2013 6:09 AM Josh Berkus wrote:
>
> >>
> >> Surely VACUUM FULL should rebuild the visibility map, and make
> tuples
> >> in
> >> the new relation all-
On Thu, Jan 10, 2013 at 11:45 AM, Amit Kapila wrote:
> On Thursday, January 10, 2013 6:09 AM Josh Berkus wrote:
>>
>> Surely VACUUM FULL should rebuild the visibility map, and make tuples
>> in
>> the new relation all-visible, no?
>
> I think it cannot made all visible.
> How about if any transac
On Thursday, January 10, 2013 6:09 AM Josh Berkus wrote:
> On 01/09/2013 03:07 PM, Bruce Momjian wrote:
> > How do we want to handle the case where VACUUM FULL clears the
> > visibility map, causing loss of index-only scans?
> >
> > http://archives.postgresql.org/pgsql-performance/2012-
> 11/ms
On 01/09/2013 03:07 PM, Bruce Momjian wrote:
> How do we want to handle the case where VACUUM FULL clears the
> visibility map, causing loss of index-only scans?
>
> http://archives.postgresql.org/pgsql-performance/2012-11/msg00317.php
>
> Do we document this behavior or add a TODO item?
>
How do we want to handle the case where VACUUM FULL clears the
visibility map, causing loss of index-only scans?
http://archives.postgresql.org/pgsql-performance/2012-11/msg00317.php
Do we document this behavior or add a TODO item?
--
Bruce Momjian http://momjian.us
Enterpr
22 matches
Mail list logo
