Re: Schema variables - new implementation for Postgres 15 (typo)

po 23. 1. 2023 v 15:25 odesílatel Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
napsal:

> > On Sun, Jan 22, 2023 at 07:47:07PM +0100, Pavel Stehule wrote:
> > pá 20. 1. 2023 v 21:35 odesílatel Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
> > napsal:
> >
> > > * I think it was already mentioned in the thread, there seems to be
> not a
> > > single usage of CHECK_FOR_INTERRUPTS in session_variable.c . But some
> > > number
> > > of loops over the sessionvars are implemented, are they always going
> to
> > > be
> > > small enough to not make any troubles?
> > >
> >
> > The longest cycle is a cycle that rechecks actively used variables
> against
> > system catalog. No cycle depends on the content of variables.
>
> Right, but what about the cases with huge number of variables? Not
> saying it could be in any sense common, but possible to do.
>

Now I tested 10K variables (with enabled assertions, without it is should
be faster)

creating 763ms

do $$ begin for i in 1..10000 loop execute format('create variable %I as
int', 'xx' || i); end loop; end $$;

assigning 491ms

do $$ begin for i in 1..10000 loop execute format('let %I = 10', 'xx' ||
i); end loop; end $$;

dropping without necessity of memory cleaning 1155ms

do $$ begin for i in 1..10000 loop execute format('drop variable %I', 'xx'
|| i); end loop; end $$;

dropping with memory cleaning 2708

just memory cleaning 72ms (time of commit - at commit cleaning)

do $$ begin for i in 1..10000 loop execute format('let %I = 10', 'xx' ||
i); end loop; end $$;
begin;
do $$ begin for i in 1..10000 loop execute format('drop variable %I', 'xx'
|| i); end loop; end $$;
commit;

So just syncing (cleaning 10K) variables needs less than 72 ms

I can be wrong, but from these numbers I don't think so these sync cycles
should to contain CHECK_FOR_INTERRUPTS

What do you think?

> > > * sync_sessionvars_all explains why is it necessary to copy
> > > xact_recheck_varids:
> > >
> > > When we check the variables, the system cache can be
> > > invalidated,
> > > and xact_recheck_varids can be enhanced.
> > >
> > > I'm not quite following what the "enhancement" part is about? Is
> > > xact_recheck_varids could be somehow updated concurrently with the
> loop?
> > >
> >
> > Yes. pg_variable_cache_callback can be called when
> > is_session_variable_valid is executed.
> >
> > Maybe "extended" can be a better word instead of "enhanced"? I
> reformulated
> > this comment
>
> Yeah, "extended" sounds better. But I was mostly confused about the
> mechanism, if the cache callback can interrupt the execution at any
> moment when called, that would explain it.
>

patch from yesterday has extended comment in this area :-)

Regards

Pavel