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