Re: Columns correlation and adaptive query optimization

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: Zhihong Yu <zyu(at)yugabyte(dot)com>
Cc: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Columns correlation and adaptive query optimization
Date: 2021-03-20 09:41:44
Message-ID: aa10f759-e591-63e3-52ec-ac1db14beabf@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 19.03.2021 20:32, Zhihong Yu wrote:
> Hi,
> In AddMultiColumnStatisticsForQual(),
>
> +   /* Loop until we considered all vars */
> +   while (vars != NULL)
> ...
> +       /* Contruct list of unique vars */
> +       foreach (cell, vars)
>
> What if some cell / node, gets into the else block:
>
> +               else
> +               {
> +                   continue;
>
> and being left in vars. Is there a chance for infinite loop ?
> It seems there should be a bool variable indicating whether any cell
> gets to the following:
>
> +           vars = foreach_delete_current(vars, cell);
>
> If no cell gets removed in the current iteration, the outer while loop
> should exit.

Each iteration of outer loop (while (vars != NULL))
process variables belonging to one relation.
We take "else continue" branch only if variable belongs to some other
relation.
At first iteration of foreach (cell, vars)
variable "cols" is NULL and we always take first branch of the if.
In other words, at each iteration of outer loop we always make some
progress in processing "vars" list and remove some elements
from this list. So infinite loop can never happen.

>
> Cheers
>
> On Fri, Mar 19, 2021 at 9:58 AM Konstantin Knizhnik
> <k(dot)knizhnik(at)postgrespro(dot)ru <mailto:k(dot)knizhnik(at)postgrespro(dot)ru>> wrote:
>
>
>
> On 19.03.2021 12:17, Yugo NAGATA wrote:
> > On Wed, 10 Mar 2021 03:00:25 +0100
> > Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com
> <mailto:tomas(dot)vondra(at)enterprisedb(dot)com>> wrote:
> >
> >> What is being proposed here - an extension suggesting which
> statistics
> >> to create (and possibly creating them automatically) is certainly
> >> useful, but I'm not sure I'd call it "adaptive query
> optimization". I
> >> think "adaptive" means the extension directly modifies the
> estimates
> >> based on past executions. So I propose calling it maybe "statistics
> >> advisor" or something like that.
> > I am also agree with the idea to implement this feature as a new
> > extension for statistics advisor.
> >
> >> BTW Why is "qual" in
> >>
> >>    static void
> >>    AddMultiColumnStatisticsForQual(void* qual, ExplainState *es)
> >>
> >> declared as "void *"? Shouldn't that be "List *"?
> > When I tested this extension using TPC-H queries, it raised
> segmentation
> > fault in this function. I think the cause would be around this
> argument.
> >
> > Regards,
> > Yugo Nagata
> >
> Attached please find new version of the patch with
> AddMultiColumnStatisticsForQual parameter type fix and one more fix
> related with handling synthetic attributes.
> I can not reproduce the crash on TPC-H queries, so if the problem
> persists, can you please send me stack trace and may be some other
> information helping to understand the reason of SIGSEGV?
>
> Thanks in advance,
> Konstantin
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2021-03-20 10:18:50 Re: [HACKERS] Custom compression methods
Previous Message Tomas Vondra 2021-03-20 09:35:26 Re: [HACKERS] Custom compression methods