I wrote:
>> Attached is a patch series that attempts to modernize our GUC
>> infrastructure, in particular removing the performance bottlenecks
>> it has when there are lots of GUC variables.
> Rebased over 0a20ff54f.
Here's a v3 rebased up to HEAD. The only real change is that I added
a couple
I wrote:
> Attached is a patch series that attempts to modernize our GUC
> infrastructure, in particular removing the performance bottlenecks
> it has when there are lots of GUC variables.
Rebased over 0a20ff54f.
regards, tom lane
commit d8b8742e80ef6f1e6546ddb9767bd846e8
On Tue, Sep 6, 2022 at 10:05 AM Tom Lane wrote:
> > I haven't looked at that patch at all, but I would assume that
> > variables would have SQL types, and that we would never add GUCs with
> > SQL types, which seems like a pretty major semantic difference.
>
> Yeah, I do not think we'd want to ext
Hi
> I think a large part of the reason the schema-variables patch
> has gone sideways for so many years is that it's an ambitious
> overdesign.
>
Last two weeks this patch is shorter and shorter. I removed a large part
related to check of type consistency, because I can do this check more
easi
Robert Haas writes:
> On Tue, Sep 6, 2022 at 1:43 AM Tom Lane wrote:
>> I think there's a good analogy here to temporary tables. The SQL
>> spec says that temp-table schemas are persistent and database-wide,
>> but what we actually have is that they are session-local.
> Well, I've thought about
On Tue, Sep 6, 2022 at 1:43 AM Tom Lane wrote:
> I think there's a good analogy here to temporary tables. The SQL
> spec says that temp-table schemas are persistent and database-wide,
> but what we actually have is that they are session-local. People
> occasionally propose that we implement the
út 6. 9. 2022 v 7:42 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > út 6. 9. 2022 v 6:32 odesílatel Pavel Stehule
> > napsal:
> >> 1. Session variables can be persistent - so the usage of session
> variables
> >> can be checked by static analyze like plpgsql_check
>
> > more precious -
Pavel Stehule writes:
> út 6. 9. 2022 v 6:32 odesílatel Pavel Stehule
> napsal:
>> 1. Session variables can be persistent - so the usage of session variables
>> can be checked by static analyze like plpgsql_check
> more precious - metadata of session variables are persistent
Right ... so the qu
Pavel Stehule writes:
> The bad performance is not the main reason for implementing session
> variables (and in almost all cases the performance of GUC is not a problem,
> because it is not a bottleneck, and in some terrible cases, I can save the
> GUC to a variable). There are other differences:
Hi,
On Tue, Sep 06, 2022 at 06:32:21AM +0200, Pavel Stehule wrote:
> Hi
>
> út 6. 9. 2022 v 0:28 odesílatel Tom Lane napsal:
>
> > Attached is a patch series that attempts to modernize our GUC
> > infrastructure, in particular removing the performance bottlenecks
> > it has when there are lots of
út 6. 9. 2022 v 6:32 odesílatel Pavel Stehule
napsal:
> Hi
>
> út 6. 9. 2022 v 0:28 odesílatel Tom Lane napsal:
>
>> Attached is a patch series that attempts to modernize our GUC
>> infrastructure, in particular removing the performance bottlenecks
>> it has when there are lots of GUC variables.
Hi
út 6. 9. 2022 v 0:28 odesílatel Tom Lane napsal:
> Attached is a patch series that attempts to modernize our GUC
> infrastructure, in particular removing the performance bottlenecks
> it has when there are lots of GUC variables. I wrote this because
> I am starting to question the schema-var
ah, yes, that makes sense ;)
On Tue, Sep 6, 2022 at 10:48 AM Tom Lane wrote:
>
> Junwang Zhao writes:
> > /*
> > - * Create table with 20% slack
> > + * Create hash table with 20% slack
> > */
> > size_vars = num_vars + num_vars / 4;
>
> > Should we change 20% to 25%, I thought that might
Junwang Zhao writes:
> /*
> - * Create table with 20% slack
> + * Create hash table with 20% slack
> */
> size_vars = num_vars + num_vars / 4;
> Should we change 20% to 25%, I thought that might be
> a typo.
No ... 20% of the allocated space is spare.
regards, tom
Hi Tom,
@@ -5836,74 +5865,106 @@ build_guc_variables(void)
}
/*
- * Create table with 20% slack
+ * Create hash table with 20% slack
*/
size_vars = num_vars + num_vars / 4;
Should we change 20% to 25%, I thought that might be
a typo.
On Tue, Sep 6, 2022 at 6:28 AM Tom Lane wrote:
>
> A
Andres Freund writes:
> It's only half related, but since we're talking about renovating guc.c: I
> think it'd be good if we split the list of GUCs from the rest of the guc
> machinery. Both for humans and compilers it's getting pretty large. And
> commonly one either wants to edit the definition
Hi,
> I wrote this because I am starting to question the schema-variables patch
> [1] --- that's getting to be quite a large patch and I grow less and less
> sure that it's solving a problem our users want solved. --- that's getting
> to be quite a large patch and I grow less and less sure that it
Attached is a patch series that attempts to modernize our GUC
infrastructure, in particular removing the performance bottlenecks
it has when there are lots of GUC variables. I wrote this because
I am starting to question the schema-variables patch [1] --- that's
getting to be quite a large patch a
18 matches
Mail list logo
