On 3/7/17 9:42 PM, Pavan Deolasee wrote:
Fair point. I'm not going to "persist" with the idea too long. It seemed
like a good, low-risk feature to me which can benefit certain use cases
quite reasonably. It's not uncommon to create indexes (or reindex
existing indexes to remove index bloats) on
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-03-07 21:38:40 -0500, Robert Haas wrote:
> > > I wonder however, if careful snapshot managment couldn't solve this as
> > > well. I have *not* thought a lot about this, but afaics we can easily
> > > prevent all-visible from being set in cases
* Pavan Deolasee (pavan.deola...@gmail.com) wrote:
> On Wed, Mar 8, 2017 at 7:33 AM, Robert Haas wrote:
>
> > On Tue, Mar 7, 2017 at 4:26 PM, Stephen Frost wrote:
> > > Right, that's what I thought he was getting at and my general thinking
> > > was that we would need a way to discover if a CIC
On 2017-03-07 21:38:40 -0500, Robert Haas wrote:
> > I wonder however, if careful snapshot managment couldn't solve this as
> > well. I have *not* thought a lot about this, but afaics we can easily
> > prevent all-visible from being set in cases it'd bother us by having an
> > "appropriate" xmin /
On Wed, Mar 8, 2017 at 8:08 AM, Robert Haas wrote:
> On Tue, Mar 7, 2017 at 9:12 PM, Andres Freund wrote:
>
> >
> > I wonder however, if careful snapshot managment couldn't solve this as
> > well. I have *not* thought a lot about this, but afaics we can easily
> > prevent all-visible from being
On Wed, Mar 8, 2017 at 7:33 AM, Robert Haas wrote:
> On Tue, Mar 7, 2017 at 4:26 PM, Stephen Frost wrote:
> > Right, that's what I thought he was getting at and my general thinking
> > was that we would need a way to discover if a CIC is ongoing on the
> > relation and therefore heap_page_prune(
On Tue, Mar 7, 2017 at 9:12 PM, Andres Freund wrote:
> On 2017-03-07 21:03:53 -0500, Robert Haas wrote:
>> On Tue, Mar 7, 2017 at 4:26 PM, Stephen Frost wrote:
>> > Right, that's what I thought he was getting at and my general thinking
>> > was that we would need a way to discover if a CIC is ong
On 2017-03-07 21:03:53 -0500, Robert Haas wrote:
> On Tue, Mar 7, 2017 at 4:26 PM, Stephen Frost wrote:
> > Right, that's what I thought he was getting at and my general thinking
> > was that we would need a way to discover if a CIC is ongoing on the
> > relation and therefore heap_page_prune(), o
On Tue, Mar 7, 2017 at 4:26 PM, Stephen Frost wrote:
> Right, that's what I thought he was getting at and my general thinking
> was that we would need a way to discover if a CIC is ongoing on the
> relation and therefore heap_page_prune(), or anything else, would know
> that it can't twiddle the b
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Mar 3, 2017 at 6:06 PM, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> >> On 2017-02-28 19:12:03 +0530, Pavan Deolasee wrote:
> >> > Since VM bits are only set during VACUUM which conflicts with CIC on the
> >>
On Fri, Mar 3, 2017 at 6:06 PM, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
>> On 2017-02-28 19:12:03 +0530, Pavan Deolasee wrote:
>> > Since VM bits are only set during VACUUM which conflicts with CIC on the
>> > relation lock, I don't see any risk of incorrectly skipping p
On 2017-03-03 15:12:04 -0800, Peter Geoghegan wrote:
> On Tue, Feb 28, 2017 at 5:42 AM, Pavan Deolasee
> wrote:
> > During the second heap scan of CREATE INDEX CONCURRENTLY, we're only
> > interested in the tuples which were inserted after the first scan was
> > started. All such tuples can only e
On Tue, Feb 28, 2017 at 5:42 AM, Pavan Deolasee
wrote:
> During the second heap scan of CREATE INDEX CONCURRENTLY, we're only
> interested in the tuples which were inserted after the first scan was
> started. All such tuples can only exists in pages which have their VM bit
> unset. So I propose th
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-02-28 19:12:03 +0530, Pavan Deolasee wrote:
> > Since VM bits are only set during VACUUM which conflicts with CIC on the
> > relation lock, I don't see any risk of incorrectly skipping pages that the
> > second scan should have scanned.
On Fri, Mar 3, 2017 at 2:54 PM, Andres Freund wrote:
> On 2017-02-28 19:12:03 +0530, Pavan Deolasee wrote:
>> Since VM bits are only set during VACUUM which conflicts with CIC on the
>> relation lock, I don't see any risk of incorrectly skipping pages that the
>> second scan should have scanned.
>
Hi,
On 2017-02-28 19:12:03 +0530, Pavan Deolasee wrote:
> Since VM bits are only set during VACUUM which conflicts with CIC on the
> relation lock, I don't see any risk of incorrectly skipping pages that the
> second scan should have scanned.
I think that's true currently, but it'd also prevent u
On Tue, Feb 28, 2017 at 10:42 PM, Pavan Deolasee
wrote:
> Hello All,
>
> During the second heap scan of CREATE INDEX CONCURRENTLY, we're only
> interested in the tuples which were inserted after the first scan was
> started. All such tuples can only exists in pages which have their VM bit
> unset.
Hello All,
During the second heap scan of CREATE INDEX CONCURRENTLY, we're only
interested in the tuples which were inserted after the first scan was
started. All such tuples can only exists in pages which have their VM bit
unset. So I propose the attached patch which consults VM during second sca
18 matches
Mail list logo
