From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Add parameter jit_warn_above_fraction |
Date: | 2022-03-29 20:35:53 |
Message-ID: | CAH2-WzmgZ_intW1FCnub_XFurgWS5Xz_hujUAyNbAyRDq-gJYA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 29, 2022 at 1:06 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> That means that even if the total execution time of a plan was a true
> reflection of the total estimated plan cost, then the fraction of time
> spent (as is measured by jit_warn_above_fraction) doing JIT would
> entirely depend on the number of expressions to compile. Of course,
> the planner's not that good, but does that not indicate that the JIT
> costing should really account for the number of expressions and not
> just the total plan cost?
That's a good point. The difference between the actual cost of
executing the query with and without JIT'ing is what we care about,
for the most part. Maybe we could do a lot better just by inventing a
fairly crude model that captures the benefits of JIT'ing -- that's
what "counting the number of expressions" sounds like to me. This
model could probably assume that JIT'ing itself was free -- maybe
something this simple would work well.
The planner has traditionally used the cost units to determine the
cheapest plan; it compared total plan cost for plans that were taken
from the universe of possible plans for *one specific query*. That's
completely different to any model that expects plan costs to be
meaningful in an absolute sense. I'm not completely sure how much that
difference matters, but I suspect that the answer is: "it depends, but
often it matters a great deal".
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-03-29 20:37:34 | Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset |
Previous Message | Thomas Munro | 2022-03-29 20:35:31 | Re: pgsql: Add 'basebackup_to_shell' contrib module. |