On Mon, Nov 20, 2023 at 4:07 AM Laurenz Albe
wrote:
> On Sun, 2023-11-19 at 17:30 +, Simon Connah wrote:
> > I was reading about prepared statements and how they allow the server to
> > plan the query in advance so that if you execute that query multiple
> times
> > it gets sped up as the dat
On Sun, 2023-11-19 at 17:30 +, Simon Connah wrote:
> I was reading about prepared statements and how they allow the server to
> plan the query in advance so that if you execute that query multiple times
> it gets sped up as the database has already done the planning work.
>
> My question is th
On Sun, Nov 19, 2023 at 11:09 AM Francisco Olarte
wrote:
> IIRC it does it once per
> transaction, but it should be in the docs.
>
There is no external caching for executing a CALL; the runtime executes the
procedure afresh each time. If it were any different that would have to be
documented.
On Sunday, 19 November 2023 at 18:09, Francisco Olarte
wrote:
>
>
> Hi Simon:
>
> On Sun, 19 Nov 2023 at 18:30, Simon Connah
> simon.n.con...@protonmail.com wrote:
>
> > I was reading about prepared statements and how they allow the server to
> > plan the query in advance so that if you
Hi Simon:
On Sun, 19 Nov 2023 at 18:30, Simon Connah
wrote:
> I was reading about prepared statements and how they allow the server to plan
> the query in advance so that if you execute that query multiple times it gets
> sped up as the database has already done the planning work.
But bear in
On Sun, Nov 19, 2023 at 10:30 AM Simon Connah
wrote:
> My question is this. If I make a stored procedure doesn't the database
> already pre-plan and optimise the query because it has access to the whole
> query?
No. Planning isn't about the text of the query, it's about the current
state of th
On Thu, Oct 26, 2023 at 10:56 AM Zain Kabani
wrote:
> I was looking into using prepared statements and using the auto
> plan_cache_mode. The issue is that the current sample of data collected to
> determine whether to use custom plans or the generic one is very small and
> susceptible to a bad se
> You mean Oracle 11g.
No 12c. Some of it may have started in 11g itself, but only in 12c they really
mastered it. I saw it as a developer, not as a DBA. I was never an oracle DBA.
Rakesh Kumar wrote:
> Only in Oracle 12c there are
> options to let the planner change existing plan by peeking into the parameter
> values (supplied in ? of prepare) and checking it against the distribution.
You mean Oracle 11g.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql
> On Mar 21, 2018, at 2:09 PM, Tim Cross wrote:
>
>
> a simple question I wasn't able to get a clear answer on
>
> It is general best practice to use prepared statements and parameters
> rather than concatenated strings to build sql statements as mitigation
> against SQL injection. However
> For example, the planner may be able to
> more easily recognise a statement and reuse an existing plan rather than
> re-planning the query.
This is a double edged sword. Reuse an existing plan can be bad in those
cases where the data distribution is not suitable for the current plan. This has
b
Robert Zenz wrote:
> We are seeing a quite heavy slow down when using prepared statements in 10.1.
>
> I haven't done some thorough testing, to be honest, but what we are having is
> a
> select from a view (complexity of it should not matter in my opinion),
> something
> like this:
>
> prep
12 matches
Mail list logo
