Stephen Frost wrote:
> Tracking the INSERTs as a reason to VACUUM is also very natural when you
> consider the need to update BRIN indexes. I am a bit worried that if we
> focus just on if the VM needs to be updated or not that we might miss
> out on cases where we need to VACUUM because the BRIN
On Sat, Jan 21, 2017 at 1:57 PM, Stephen Frost wrote:
> All,
>
> * Simon Riggs (si...@2ndquadrant.com) wrote:
> > On 12 August 2016 at 01:01, Tom Lane wrote:
> > > Michael Paquier writes:
> > >> In short, autovacuum will need to scan by itself the VM of each
> > >> relation and decide based on
On Sun, Jan 22, 2017 at 4:45 PM, Stephen Frost wrote:
> Amit,
>
> * Amit Kapila (amit.kapil...@gmail.com) wrote:
> > On Sun, Jan 22, 2017 at 3:27 AM, Stephen Frost
> wrote:
> > > * Simon Riggs (si...@2ndquadrant.com) wrote:
> > >> On 12 August 2016 at 01:01, Tom Lane wrote:
> > >> > Michael Paq
Amit,
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> On Sun, Jan 22, 2017 at 3:27 AM, Stephen Frost wrote:
> > * Simon Riggs (si...@2ndquadrant.com) wrote:
> >> On 12 August 2016 at 01:01, Tom Lane wrote:
> >> > Michael Paquier writes:
> >> >> In short, autovacuum will need to scan by itself
On Sun, Jan 22, 2017 at 3:27 AM, Stephen Frost wrote:
> All,
>
> * Simon Riggs (si...@2ndquadrant.com) wrote:
>> On 12 August 2016 at 01:01, Tom Lane wrote:
>> > Michael Paquier writes:
>> >> In short, autovacuum will need to scan by itself the VM of each
>> >> relation and decide based on that.
All,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 12 August 2016 at 01:01, Tom Lane wrote:
> > Michael Paquier writes:
> >> In short, autovacuum will need to scan by itself the VM of each
> >> relation and decide based on that.
> >
> > That seems like a worthwhile approach to pursue. The V
On 12 August 2016 at 01:01, Tom Lane wrote:
> Michael Paquier writes:
>> In short, autovacuum will need to scan by itself the VM of each
>> relation and decide based on that.
>
> That seems like a worthwhile approach to pursue. The VM is supposed to be
> small, and if you're worried it isn't, yo
On Thu, Aug 11, 2016 at 9:29 PM, Jeff Janes wrote:
> On Thu, Aug 11, 2016 at 8:32 AM, Amit Kapila wrote:
>> On Thu, Aug 11, 2016 at 2:09 AM, Jeff Janes wrote:
>>> I wanted to create a new relopt named something like
>>> autovacuum_vacuum_pagevisible_factor which would cause autovacuum to
>>> vac
On 12/08/16 15:15, Peter Eisentraut wrote:
> On 8/11/16 11:59 AM, Jeff Janes wrote:
>> Insertions and HOT-updates clear vm bits but don't increment the
>> counters that those existing parameters are compared to.
>>
>> Also, the relationship between number of updated/deleted rows and the
>> number o
On 8/11/16 11:59 AM, Jeff Janes wrote:
> Insertions and HOT-updates clear vm bits but don't increment the
> counters that those existing parameters are compared to.
>
> Also, the relationship between number of updated/deleted rows and the
> number of hint-bits cleared can be hard to predict due to
On Fri, Aug 12, 2016 at 9:01 AM, Tom Lane wrote:
> Michael Paquier writes:
>> In short, autovacuum will need to scan by itself the VM of each
>> relation and decide based on that.
>
> That seems like a worthwhile approach to pursue. The VM is supposed to be
> small, and if you're worried it isn'
On 8/11/16 10:59 AM, Jeff Janes wrote:
On Thu, Aug 11, 2016 at 8:32 AM, Amit Kapila wrote:
On Thu, Aug 11, 2016 at 2:09 AM, Jeff Janes wrote:
I wanted to create a new relopt named something like
autovacuum_vacuum_pagevisible_factor which would cause autovacuum to
vacuum a table once less than
Michael Paquier writes:
> In short, autovacuum will need to scan by itself the VM of each
> relation and decide based on that.
That seems like a worthwhile approach to pursue. The VM is supposed to be
small, and if you're worried it isn't, you could sample a few pages of it.
I do not think any o
On Thu, Aug 11, 2016 at 4:21 PM, Michael Paquier
wrote:
> On Thu, Aug 11, 2016 at 3:29 PM, Michael Paquier
> wrote:
>> On Thu, Aug 11, 2016 at 5:39 AM, Jeff Janes wrote:
>>> I wanted to create a new relopt named something like
>>> autovacuum_vacuum_pagevisible_factor which would cause autovacuum
On Thu, Aug 11, 2016 at 8:32 AM, Amit Kapila wrote:
> On Thu, Aug 11, 2016 at 2:09 AM, Jeff Janes wrote:
>> I wanted to create a new relopt named something like
>> autovacuum_vacuum_pagevisible_factor which would cause autovacuum to
>> vacuum a table once less than a certain fraction of the relat
On Thu, Aug 11, 2016 at 2:09 AM, Jeff Janes wrote:
> I wanted to create a new relopt named something like
> autovacuum_vacuum_pagevisible_factor which would cause autovacuum to
> vacuum a table once less than a certain fraction of the relation's
> pages are marked allvisible.
>
Why would it more
On Thu, Aug 11, 2016 at 3:29 PM, Michael Paquier
wrote:
> On Thu, Aug 11, 2016 at 5:39 AM, Jeff Janes wrote:
>> I wanted to create a new relopt named something like
>> autovacuum_vacuum_pagevisible_factor which would cause autovacuum to
>> vacuum a table once less than a certain fraction of the r
On Thu, Aug 11, 2016 at 5:39 AM, Jeff Janes wrote:
> I wanted to create a new relopt named something like
> autovacuum_vacuum_pagevisible_factor which would cause autovacuum to
> vacuum a table once less than a certain fraction of the relation's
> pages are marked allvisible.
Interesting idea.
>
I wanted to create a new relopt named something like
autovacuum_vacuum_pagevisible_factor which would cause autovacuum to
vacuum a table once less than a certain fraction of the relation's
pages are marked allvisible.
I wanted some feedback on some things.
1) One issue is that pg_class.relpages a
19 matches
Mail list logo
