> On 14 Jul 2021, at 13:13, vignesh C wrote:
> "C:\projects\postgresql\pgsql.sln" (default target) (1) ->
> "C:\projects\postgresql\auto_explain.vcxproj" (default target) (45) ->
> (ClCompile target) ->
> contrib/auto_explain/auto_explain.c(658): error C2039: 'mt_plans' : is
> not a member of
; >> 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
GATA wrote:
> > > On Wed, 10 Mar 2021 03:00:25 +0100
> > > Tomas Vondra > <mailto:tomas.von...@enterprisedb.com>> wrote:
> > >
> > >> What is being proposed here - an extension suggesting which
> > statistics
>
gt;> 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 executio
xtension 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
esti
- 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 modifi
On 19.03.2021 12:17, Yugo NAGATA wrote:
On Wed, 10 Mar 2021 03:00:25 +0100
Tomas Vondra 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
On Wed, 10 Mar 2021 03:00:25 +0100
Tomas Vondra 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
>
On 3/10/21 3:00 AM, Tomas Vondra wrote:
> Hello Konstantin,
>
>
> Sorry for not responding to this thread earlier. I definitely agree the
> features proposed here are very interesting and useful, and I appreciate
> you kept rebasing the patch.
>
> I think the patch improving join estimates can
a separate CF entry - it however still points
to this thread, which will be confusing. I suggest we start a different
thread for it, to keep the discussions separate.
I'll focus on the auto_explain part here.
I did have some ideas about adaptive query optimization too, although
maybe in a slightly
the clausesel patch uses only functional dependencies statistics for
improving join, so my question was about possibility to consider MCV in the
clausesel patch.
(10)
To achieve adaptive query optimization (AQO) in PostgreSQL, this patch proposes
to use auto_explain for getting feedback fro
rding to the documentation all supported statistics kinds should be
> created in this case:
Yes, auto_explain creates all kinds of extended statistics. However,
IIUC, the clausesel patch uses only functional dependencies statistics for
improving join, so my question was about possibility to
Hello,
Thank you for review.
My answers are inside.
On 21.01.2021 15:30, Yugo NAGATA wrote:
Hello,
On Thu, 26 Mar 2020 18:49:51 +0300
Konstantin Knizhnik wrote:
Attached please find new version of the patch with more comments and
descriptions added.
Adaptive query optimization is very
Hello,
On Thu, 26 Mar 2020 18:49:51 +0300
Konstantin Knizhnik wrote:
> Attached please find new version of the patch with more comments and
> descriptions added.
Adaptive query optimization is very interesting feature for me, so I looked
into this patch. Here are some comments and que
On 25.03.2020 20:04, Rafia Sabih wrote:
Also, there is no description about any of the functions here,
wouldn’t hurt having some more comments there.
Attached please find new version of the patch with more comments and
descriptions added.
--
Konstantin Knizhnik
Postgres Professional:
Thank you very much for review.
On 25.03.2020 20:04, Rafia Sabih wrote:
+static void
+AddMultiColumnStatisticsForNode(PlanState *planstate, ExplainState *es);
+
This doesn't look like the right place for it, you might want to
declare it with other functions in the starting of the file.
Also,
Hello,
This sounded like an interesting addition to postgresql. I gave some
time to it today to review, here are few comments,
On Wed, 25 Mar 2020 at 14:28, Konstantin Knizhnik
wrote:
>
>
>
> On 25.03.2020 16:00, David Steele wrote:
> > On 3/25/20 6:57 AM, Konstantin Knizhnik wrote:
> >>
> >>
>
On 25.03.2020 16:00, David Steele wrote:
On 3/25/20 6:57 AM, Konstantin Knizhnik wrote:
On 24.03.2020 20:12, David Steele wrote:
On 12/24/19 3:15 AM, Konstantin Knizhnik wrote:
New version of patch implicitly adding multicolumn statistic in
auto_explain extension and using it in optimizer
On 3/25/20 6:57 AM, Konstantin Knizhnik wrote:
On 24.03.2020 20:12, David Steele wrote:
On 12/24/19 3:15 AM, Konstantin Knizhnik wrote:
New version of patch implicitly adding multicolumn statistic in
auto_explain extension and using it in optimizer for more precise
estimation of join
On 24.03.2020 20:12, David Steele wrote:
On 12/24/19 3:15 AM, Konstantin Knizhnik wrote:
New version of patch implicitly adding multicolumn statistic in
auto_explain extension and using it in optimizer for more precise
estimation of join selectivity.
This patch fixes race condition while
On 12/24/19 3:15 AM, Konstantin Knizhnik wrote:
New version of patch implicitly adding multicolumn statistic in
auto_explain extension and using it in optimizer for more precise
estimation of join selectivity.
This patch fixes race condition while adding statistics and restricts
generated
New version of patch implicitly adding multicolumn statistic in
auto_explain extension and using it in optimizer for more precise
estimation of join selectivity.
This patch fixes race condition while adding statistics and restricts
generated statistic name to fit in 64 bytes (NameData).
--
Smarter version of join selectivity patch handling cases like this:
explain select * from outer_tab join inner_tab using(x,y) where x=1;
QUERY PLAN
Nested
On 15.10.2019 1:20, legrand legrand wrote:
Hello Konstantin,
What you have proposed regarding join_selectivity and multicolumn statistics
is a very good new !
Regarding your auto_explain modification, maybe an "advisor" mode would also
be helpfull (with
Hello Konstantin,
What you have proposed regarding join_selectivity and multicolumn statistics
is a very good new !
Regarding your auto_explain modification, maybe an "advisor" mode would also
be helpfull (with auto_explain_add_statistics_threshold=-1 for exemple).
This would allow to track
Hi hackers,
Errors in selectivity estimations is one of the main reason of bad plans
generation by Postgres optimizer.
Postgres estimates selectivity based on the collected statistic
(histograms).
While it is able to more or less precisely estimated selectivity of
simple predicate for
On Thu, Jun 13, 2019 at 03:17:07PM +0200, Rafia Sabih wrote:
On Thu, 13 Jun 2019 at 06:07, Kuntal Ghosh wrote:
On Thu, Jun 13, 2019 at 5:49 AM Tomas Vondra
wrote:
>
> >> ...
> >>
> >That'll be an interesting work. For the above query, we can definitely
> >calculate the correction coefficient
On Thu, Jun 13, 2019 at 09:37:07AM +0530, Kuntal Ghosh wrote:
On Thu, Jun 13, 2019 at 5:49 AM Tomas Vondra
wrote:
For example, we might require 1000 samples for a given node (say, scan
with some quals), before we start using it to tweak the estimates. Once
we get the number of estimates, we
On Thu, 13 Jun 2019 at 06:07, Kuntal Ghosh wrote:
>
> On Thu, Jun 13, 2019 at 5:49 AM Tomas Vondra
> wrote:
> >
> > For example, we might require 1000 samples for a given node (say, scan
> > with some quals), before we start using it to tweak the estimates. Once
> > we get the number of
On Thu, Jun 13, 2019 at 5:49 AM Tomas Vondra
wrote:
>
> For example, we might require 1000 samples for a given node (say, scan
> with some quals), before we start using it to tweak the estimates. Once
> we get the number of estimates, we can continue collecting more data,
> and once in a while
y wouldn't consider this part of adaptive query
optimization, but it probably makes sense to make it part of this. I
wonder if we might improve this to also suggest "missing" indexes?
I like this part of the implementation. I also agree that this can be
used to come up with good hypothetic
ng in clauses
> with large estimation error.
>
>
> Interesting! I probably wouldn't consider this part of adaptive query
> optimization, but it probably makes sense to make it part of this. I
> wonder if we might improve this to also suggest "missing" indexes?
>
I like this
n
clauses with large estimation error.
Interesting! I probably wouldn't consider this part of adaptive query
optimization, but it probably makes sense to make it part of this. I
wonder if we might improve this to also suggest "missing" indexes?
I think that it should be nest step of adaptiv
multicolumn statistics for variables using in
>>clauses with large estimation error.
>Interesting! I probably wouldn't consider this part of adaptive query
>optimization, but it probably makes sense to make it part of this. I
>wonder if we might improve this to also suggest "
the imporant aspects of
the data distribution.
And finally, we only know how to use those stats for specific types of
clauses (equality, inequality, ...) with very simple expressions. But
that's often not what the users do.
I think adaptive query optimization - in the sense of collecting data
f
Hello,
this seems very interesting and make me think about 2 other projets:
- https://github.com/trustly/pg_badplan
- https://github.com/ossc-db/pg_plan_advsr
As I understand all this, there are actually 3 steps:
- compare actual / estimated rows
- suggests some statistics gathering modification
36 matches
Mail list logo
