| From: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> | 
|---|---|
| To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> | 
| Cc: | 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-22 02:29:25 | 
| Message-ID: | 20210322112925.cb2395d07157adfc84ce7ed7@sraoss.co.jp | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Fri, 19 Mar 2021 19:58:27 +0300
Konstantin Knizhnik <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> 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?
I also could not reproduce the segfault. I don't know why I observed it,
but it may be because I missed something when installing. Sorry for
annoying you.
Instead, I observed "ERROR:  cache lookup failed for attribute 6 of
relation xxxx" in v8 patch, but this was fixed in v9 patch.
Regards,
Yugo Nagata
-- 
Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2021-03-22 02:29:51 | Re: Add client connection check during the execution of the query | 
| Previous Message | Amit Kapila | 2021-03-22 02:27:15 | Re: replication cleanup code incorrect way to use of HTAB HASH_REMOVE ? |