On 10/26/18, Christoph Moench-Tegeder <cmt@xxxxxxxxxxxxxx> wrote: > ## GPT (gptmailinglists@xxxxxxxxx): > >... > > And the important thing is: there is no guarantee that the same SQL > statement will always execute with the same plan: + Yes but there should be guarantee that when the statement is free of any syntactic error to be executed successfully and return the expected result!!! This is out of discussion and any negotiation!!! + If I construct a ship, or an airplane or a car and you turn the wheel to the right and the vessel, at sixth time, turns to the left and you have even a minor crash you are not gonna accept any excuse about the turning wheel plan change!!! + Here, there is an obvious problem: The outcome of a correct syntactically statement is not the expected one. It is very very simple! Simpler cannot be done! Only if you keep your eyes sealed closed you cannot see it; but even then you can hear the warnings that something is wrong. + > One reason would be > changing table statistics, + As a reason is accepted, but as an excuse in order to stay inactive it is not. + > another is when PostgreSQL switches to > the generic plan for a prepared statement. + Same as above. + > Your case looks like the > latter, especially the observation "After that (6th time)" in > https://github.com/nahanni/rw_redis_fdw/issues/13#issuecomment-428670890 > hints to that. > So, where does that prepared statement come from? You don't really > describe your environment... + Ask me what ever you believe you need to find the reason of the failure! That´s why I have sent a message to the mailing list! I am not looking for a date! The minimum I was expecting was to be asked plenty questions by developers. But it never has happened! + So, aaaaaaaaaask me, please! + > It's unlikely that you're calling PREPARE > yourself - but some drivers are notorious for that (Perl DBI's > $dbh->prepare() or JDBC's PreparedStatement come to mind), + Oh, excellent! I usually use DBeaver as a GUI which uses JDBC. + (By the way, I grub the opportunity. I use DBeaver because Admin III does not work properly with pg10 and 11 and BECAUSE Admin4 is a NIGHTMARE to install it and make it to work (from the point of a simple user!!!)) + > even PL/pgSQL uses prepared statements internally: > https://www.postgresql.org/docs/11/static/plpgsql-implementation.html#PLPGSQL-PLAN-CACHING + Ah, this is an internal part! + So, so far, we have two candidates which maybe responsible for the outcome failure: JDBC and PL. + What else you need from me to help you find out the source of the problem? + If JDBC is responsible for the problem, we can inform the developers to fix the problem, if they want to hear, of course! + If PL is responsible for the problem, then pg developers most probably will state "It is not a problem, it is a project decision to behave like this! ..." > > So: plans are not stable between query executions, and you may have > prepared statements without knowing that. + SO WHAT! Does this mean that I have to accept the failure because plan has decided to change! + + So, if there is an airplane crash due to an autopilot unstable self-change, we will say ´Eh, guys no problem. Autopilot changed its plan and decided to land improperly!´ + Or if your car uses the braking system unexpectfully, and makes your car stop will running in high-velocity lane, and the rear car chashes at you back, what are you gonna say ´Eh, guys no problem, from time to time my car likes passive doggy-style crashes!´ + + That´s TRAGIC! > > Regards, > Christoph > > -- > Spare Space. > >
