From: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Dave Cramer <pg(at)fastcrypt(dot)com> |
Subject: | Re: Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102 |
Date: | 2016-01-13 10:44:31 |
Message-ID: | CAB=Je-HG1=VBixViLtL4UZgqz15Ou5p0nffq19soP=sVK5ghLg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
>the implementation is simply - but it hard to design some really general - it is task for UI
Can you please rephrase?
Current design is "if the cost of a generic plan is less than the one
of a custom plan+replan, prefer generic".
I think that is wrong.
"Generic plan" misunderestimates a cost in a sense that it assumes
some pre-defined selectivities.
In other words, if "skewed" values are used, "custom plan" would
likely to have *worse cost* than the one of a generic plan, yet custom
plan is much more suitable for a particular parameter set.
As backend refers to boundParams, it does see that particular
condition is tough, while generic estimator just the cost.
Looking into plancache.c comments I see 3 possible plans:
1) custom plan with PARAM_FLAG_CONST=1. It should probably
constant-fold based on input parameters.
2) custom plan with PARAM_FLAG_CONST=0. I think it should just use
given parameters for selectivity estimations. The generated plan
should still be valid for use with other input values.
3) generic plan. The plan with all variables. <-- here's current behavior
1 has a replan cost.
2&3 can be cached and reused.
Is that correct?
I think #2 is better option than #3 since it gives better plan
stability, thus it is much easier to test and reason about.
This all boils down to adjustment in a single line:
https://github.com/postgres/postgres/blob/ee943004466418595363d567f18c053bae407792/src/backend/utils/cache/plancache.c#L1151-L1152
Does that make sense?
Vladimir
From | Date | Subject | |
---|---|---|---|
Next Message | Anastasia Lubennikova | 2016-01-13 12:56:49 | Re: WIP: Covering + unique indexes. |
Previous Message | Amit Kapila | 2016-01-13 08:19:03 | Re: ExecGather() + nworkers |
From | Date | Subject | |
---|---|---|---|
Next Message | Enrico Olivelli - Diennea | 2016-01-13 11:04:45 | Error on setAutoCommit with 9.4.1207 |
Previous Message | Sehrope Sarkuni | 2016-01-13 02:58:28 | Re: Maven Artifact JDK Suffix |