On Sun, Jun 20, 2021 at 9:22 AM Mark Dilger
wrote:
> I'd want to see some evidence that the GUC is necessary. (For that matter,
> why is a per relation setting necessary?) Is there a reproducible
> pathological case, perhaps with a pgbench script, to demonstrate the need?
> I'm not asking wh
> On Jun 14, 2021, at 7:46 PM, Peter Geoghegan wrote:
>
> Does anyone else have an opinion on this? Of course I can easily add a
> GUC. But I won't do so in the absence of any real argument in favor of
> it.
I'd want to see some evidence that the GUC is necessary. (For that matter, why
is a
On Thu, Jun 17, 2021 at 7:26 PM Peter Geoghegan wrote:
> Thanks for the review!
>
> Attached is v3, which has all the changes that you suggested (plus the
> doc stuff from Justin).
Just pushed a version of that with much improved documentation.
Thanks again
--
Peter Geoghegan
On Thu, Jun 17, 2021 at 5:55 AM Justin Pryzby wrote:
> (Various sgml typos)
Fixed in the v3 I just posted.
> + removed until index cleanup is completed. This option has no
> + effect for tables that do not have an index and is ignored if
> + the FULL option is used.
>
> I'd say "
On Thu, Jun 17, 2021 at 2:14 AM Masahiko Sawada wrote:
> Thank you for updating the patch! Here are comments on v2 patch:
Thanks for the review!
Attached is v3, which has all the changes that you suggested (plus the
doc stuff from Justin).
I also renamed the "default" VacOptTernaryValue (actual
+ AUTO. With OFF index
+ cleanup is disabled, with ON it is enabled,
OFF comma
+ bypassing index cleanup in cases where there is more than zero
+ dead tuples.
*are* more than zero
Or (preferably): "cases when there are no dead tuples at all"
+ If INDEX_CLEANUP is set t
On Thu, Jun 17, 2021 at 10:54 AM Peter Geoghegan wrote:
>
> On Sun, May 30, 2021 at 6:30 PM Masahiko Sawada wrote:
> > We need to accept "yes" and "no" too? Currently, the parsing of a
> > boolean type reloption accepts those words.
>
> Added those in the attached revision, version 2. This is muc
On Sun, May 30, 2021 at 6:30 PM Masahiko Sawada wrote:
> We need to accept "yes" and "no" too? Currently, the parsing of a
> boolean type reloption accepts those words.
Added those in the attached revision, version 2. This is much closer
to being commitable than v1 was. I plan on committing this
On Mon, Jun 14, 2021 at 5:23 PM Michael Paquier wrote:
> > *Why* does it have to work at the system level? I don't understand
> > what you mean about the system level.
>
> I mean that you lack a GUC that allows to enforce to *not* use this
> optimization for all relations, for all processes.
You'
On Fri, Jun 11, 2021 at 02:46:20PM -0700, Peter Geoghegan wrote:
> On Thu, Jun 3, 2021 at 11:15 PM Michael Paquier wrote:
>> I have read through the patch, and I am surprised to see that this
>> only makes possible to control the optimization at relation level.
>> The origin of the complaints is t
On Sun, May 30, 2021 at 6:30 PM Masahiko Sawada wrote:
> > Another concern with this approach is what it
> > means for the VACUUM command itself. I haven't added an 'auto'
> > spelling that is accepted by the VACUUM command in this POC version.
> > But do I need to at all? Can that just be implied
On Thu, Jun 3, 2021 at 11:15 PM Michael Paquier wrote:
> I have read through the patch, and I am surprised to see that this
> only makes possible to control the optimization at relation level.
> The origin of the complaints is that this index cleanup optimization
> has been introduced as a new rul
On Fri, Jun 4, 2021 at 3:15 PM Michael Paquier wrote:
>
> On Mon, May 31, 2021 at 10:30:08AM +0900, Masahiko Sawada wrote:
> > On Fri, May 28, 2021 at 9:53 AM Peter Geoghegan wrote:
> >> Another concern with this approach is what it
> >> means for the VACUUM command itself. I haven't added an 'au
On Mon, May 31, 2021 at 10:30:08AM +0900, Masahiko Sawada wrote:
> On Fri, May 28, 2021 at 9:53 AM Peter Geoghegan wrote:
>> Another concern with this approach is what it
>> means for the VACUUM command itself. I haven't added an 'auto'
>> spelling that is accepted by the VACUUM command in this PO
On Fri, May 28, 2021 at 9:53 AM Peter Geoghegan wrote:
>
> On Sun, May 23, 2021 at 11:34 PM Masahiko Sawada
> wrote:
> > I think the possible side effect of this hard-coded
> > BYPASS_THRESHOLD_PAGES would be that by default, bulkdelete is not
> > called for a long term and the index becomes blo
On Sun, May 23, 2021 at 11:34 PM Masahiko Sawada wrote:
> I think the possible side effect of this hard-coded
> BYPASS_THRESHOLD_PAGES would be that by default, bulkdelete is not
> called for a long term and the index becomes bloat.
What do you think of the approach taken in the attached POC patc
On Wed, May 19, 2021 at 6:09 AM Peter Geoghegan wrote:
>
> On Tue, May 18, 2021 at 7:29 AM Masahiko Sawada wrote:
> > If this skipping
> > behavior badly affects other indexes AMs, this optimization should be
> > considered within btree indexes, although we will need a way for index
> > AMs to co
On Tue, May 18, 2021 at 7:29 AM Masahiko Sawada wrote:
> I prefer to have an on/off switch just in case. I remember I also
> commented the same thing before. We’ve discussed a way to control
> whether or not to enable the skipping optimization by adding a new
> mode to INDEX_CLEANUP option, as Pet
(I had missed this discussion due to the mismatched thread subject..)
On Fri, May 14, 2021 at 11:14 AM Michael Paquier wrote:
>
> On Thu, May 13, 2021 at 01:27:44PM -0700, Peter Geoghegan wrote:
> > Almost all of the benefit of the optimization is available with the
> > current BYPASS_THRESHOLD_P
On Thu, May 13, 2021 at 7:14 PM Michael Paquier wrote:
> Perhaps that's an awful deal, but based on which facts can you really
> say that this new behavior of needing at least 2% of relation pages
> with some dead items to clean up indexes is not a worse deal in some
> cases?
If I thought that it
On Thu, May 13, 2021 at 01:27:44PM -0700, Peter Geoghegan wrote:
> Almost all of the benefit of the optimization is available with the
> current BYPASS_THRESHOLD_PAGES threshold (2% of heap pages have
> LP_DEAD items), which has less risk than a higher threshold. I don't
> think it matters much if
On Thu, May 13, 2021 at 5:06 AM Justin Pryzby wrote:
> Why is the allowed range from 0 to 0.05? Why not 0.10 or 1.0 ?
> The old GUC of the same name had max 1e10.
It also had a completely different purpose and default.
> I think a reduced range and a redefinition of the GUC would need to be cal
On Thu, May 13, 2021 at 04:27:47PM +0900, Michael Paquier wrote:
> On Tue, May 11, 2021 at 04:42:27PM +0900, Michael Paquier wrote:
> > Whatever the solution chosen, the thing I can see we agree on here is
> > that we need to do something, at least in the shape of an on/off
> > switch to have an es
On Tue, May 11, 2021 at 04:42:27PM +0900, Michael Paquier wrote:
> Whatever the solution chosen, the thing I can see we agree on here is
> that we need to do something, at least in the shape of an on/off
> switch to have an escape path in case of problems. Peter, could we
> get something by beta1
On Mon, Apr 12, 2021 at 06:12:18PM -0700, Peter Geoghegan wrote:
> One of the dangers of high BYPASS_THRESHOLD_PAGES settings is that
> it'll work well for some indexes but not others. To a dramatic degree,
> even.
>
> That said, nbtree isn't the only index AM, and it is hard to be
> completely su
On Mon, Apr 12, 2021 at 5:37 PM Andres Freund wrote:
> Well, one argument is that you made a fairly significant behavioural
> change, with hard-coded logic for when the optimization kicks in. It's
> not at all clear that your constants are the right ones for every
> workload.
(Apparently nobody w
Hi,
On 2021-04-12 16:53:47 -0700, Peter Geoghegan wrote:
> On Mon, Apr 12, 2021 at 4:52 PM Michael Paquier wrote:
> > While going through this commit a couple of days ago, I really got to
> > wonder why you are controlling this stuff with a hardcoded value and I
> > found that scary, while what y
On Mon, Apr 12, 2021 at 4:52 PM Michael Paquier wrote:
> While going through this commit a couple of days ago, I really got to
> wonder why you are controlling this stuff with a hardcoded value and I
> found that scary, while what you should be using are two GUCs with the
> reloptions that come wi
On Mon, Apr 12, 2021 at 04:35:13PM -0700, Peter Geoghegan wrote:
> On Mon, Apr 12, 2021 at 4:30 PM Andres Freund wrote:
> > As far as I can see there's no reasonable way to disable this
> > "optimization", which scares me.
>
> I'm fine with adding a simple 'off' switch. What I'd like to avoid
> d
On Mon, Apr 12, 2021 at 4:30 PM Andres Freund wrote:
> As far as I can see there's no reasonable way to disable this
> "optimization", which scares me.
I'm fine with adding a simple 'off' switch. What I'd like to avoid
doing is making the behavior tunable, since it's likely to change in
Postgres
Hi,
On 2021-04-12 16:11:59 -0700, Peter Geoghegan wrote:
> Recent work from commit 5100010e taught VACUUM that it doesn't have to
> do index vacuuming in cases where there are practically zero (not
> necessarily exactly zero) tuples to delete from indexes.
FWIW, I'd not at all be surprised if thi
31 matches
Mail list logo
