> 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 'Mo
; >> 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
7, Yugo NAGATA 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
> > statistic
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 pas
ion 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 th
- 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 direc
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 "
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 b
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 sli
tatistics. However,
IIUC, 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 g
t; of statistic kind.
> According 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 w
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: htt
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 selecti
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 addi
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 stati
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).
--
Kon
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 auto_explain_add_statistics_threshold=-
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 which
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 particul
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 ca
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 estimates
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 upd
timation 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 part of the implementation. I also agree that thi
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 "missing" i
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 "missing" in
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 "
t may not be sufficient to "capture" 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 o
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
