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.
17 matches
Mail list logo
