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
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. It also
surfaces the information used to decide whether or not we skip index
vacuuming in the logs, via t
32 matches
Mail list logo
