Re: queryId constant squashing does not support prepared statements

> > To clarify, I had in mind something like in the attached patch. The > > idea is to make start/end location capturing relatively independent from > > the constants squashing. The new parsing node conveys the location > > information, which is then getting transformed to be a part of an > > Array

Re: queryId constant squashing does not support prepared statements

> On Fri, May 09, 2025 at 08:47:58AM GMT, Michael Paquier wrote: > SELECT query, calls FROM pg_stat_statements ORDER BY query COLLATE "C"; > - query| calls > -+--- > - SELECT ARRAY[$1 /*, ... */]

Re: queryId constant squashing does not support prepared statements

> On Fri, May 09, 2025 at 02:35:33PM GMT, Michael Paquier wrote: > On Fri, May 09, 2025 at 11:05:43AM +0800, Junwang Zhao wrote: > > Why not a location and a length, it should be more natural, it > > seems we use this convention in some existing nodes, like > > RawStmt, InsertStmt etc. > > These ar

Re: queryId constant squashing does not support prepared statements

On Fri, May 9, 2025 at 1:35 PM Michael Paquier wrote: > > On Fri, May 09, 2025 at 11:05:43AM +0800, Junwang Zhao wrote: > > Why not a location and a length, it should be more natural, it > > seems we use this convention in some existing nodes, like > > RawStmt, InsertStmt etc. > > These are new co

Re: queryId constant squashing does not support prepared statements

On Fri, May 09, 2025 at 11:05:43AM +0800, Junwang Zhao wrote: > Why not a location and a length, it should be more natural, it > seems we use this convention in some existing nodes, like > RawStmt, InsertStmt etc. These are new concepts as of Postgres 18 (aka only on HEAD), chosen mainly to match

Re: queryId constant squashing does not support prepared statements

Hi Dmitry, On Fri, May 9, 2025 at 3:36 AM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > On Thu, May 08, 2025 at 02:22:00PM GMT, Michael Paquier wrote: > > On Wed, May 07, 2025 at 10:41:22AM +0200, Dmitry Dolgov wrote: > > > Ah, I see what you mean. I think the idea is fine, it will simplify >

Re: queryId constant squashing does not support prepared statements

On Thu, May 08, 2025 at 03:50:32PM -0500, Sami Imseih wrote: > On Thu, May 8, 2025 at 2:36 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: >> To clarify, I had in mind something like in the attached patch. The >> idea is to make start/end location capturing relatively independent from >> the consta

Re: queryId constant squashing does not support prepared statements

On Thu, May 8, 2025 at 2:36 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > On Thu, May 08, 2025 at 02:22:00PM GMT, Michael Paquier wrote: > > On Wed, May 07, 2025 at 10:41:22AM +0200, Dmitry Dolgov wrote: > > > Ah, I see what you mean. I think the idea is fine, it will simplify > > > certain

Re: queryId constant squashing does not support prepared statements

> On Thu, May 08, 2025 at 02:22:00PM GMT, Michael Paquier wrote: > On Wed, May 07, 2025 at 10:41:22AM +0200, Dmitry Dolgov wrote: > > Ah, I see what you mean. I think the idea is fine, it will simplify > > certain things as well as address the issue. But I'm afraid adding > > start/end location to

Re: queryId constant squashing does not support prepared statements

On Wed, May 07, 2025 at 10:41:22AM +0200, Dmitry Dolgov wrote: > Ah, I see what you mean. I think the idea is fine, it will simplify > certain things as well as address the issue. But I'm afraid adding > start/end location to A_Expr is a bit too invasive, as it's being used > for many other purpose

Re: queryId constant squashing does not support prepared statements

> On Tue, May 06, 2025 at 03:01:32PM GMT, Sami Imseih wrote: > > > Without properly accounting for the boundaries of the list of > > > expressions, i.e., > > > the start and end positions of '(' and ')' or '[' and ']' and normalizing > > > the > > > expressions in between, it will be very difficu

Re: queryId constant squashing does not support prepared statements

On Tue, May 06, 2025 at 01:32:48PM -0500, Sami Imseih wrote: > Without properly accounting for the boundaries of the list of expressions, > i.e., > the start and end positions of '(' and ')' or '[' and ']' and normalizing the > expressions in between, it will be very difficult for the normalizatio

Re: queryId constant squashing does not support prepared statements

> > Without properly accounting for the boundaries of the list of expressions, > > i.e., > > the start and end positions of '(' and ')' or '[' and ']' and normalizing > > the > > expressions in between, it will be very difficult for the normalization to > > behave sanely. > > I don't think having

Re: queryId constant squashing does not support prepared statements

> On Tue, May 06, 2025 at 01:32:48PM GMT, Sami Imseih wrote: > > I also agree with Alvaro that this discussion doesn't justify a > > revert. If the pre-v18 behavior wasn't chiseled on stone tablets, > > the new behavior isn't either. We can improve it some more later. > > As I was looking further

Re: queryId constant squashing does not support prepared statements

> I also agree with Alvaro that this discussion doesn't justify a > revert. If the pre-v18 behavior wasn't chiseled on stone tablets, > the new behavior isn't either. We can improve it some more later. As I was looking further into what we currently have in v18 and HEAD the normalization could b

Re: queryId constant squashing does not support prepared statements

> On Tue, May 06, 2025 at 11:50:07PM GMT, Junwang Zhao wrote: > Would it make sense to rename `RecordConstLocation` to something like > `RecordExpressionLocation` instead? Yeah, naming is hard. RecordExpressionLocation is somehow more vague, but I see what you mean, maybe something along these lin

Re: queryId constant squashing does not support prepared statements

Hi Dmitry, On Sun, May 4, 2025 at 6:19 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > On Thu, May 01, 2025 at 09:55:47PM GMT, Dmitry Dolgov wrote: > > > On Thu, May 01, 2025 at 09:29:13AM GMT, Michael Paquier wrote: > > > > > > I agree that the current solution we have in the tree feels inc

Re: queryId constant squashing does not support prepared statements

Michael Paquier writes: > On Thu, May 01, 2025 at 03:57:16PM -0500, Sami Imseih wrote: >> I think what we should really allow the broader scope of expressions that >> are allowed via prepared statements, and this will make this implementation >> consistent between pre

Re: queryId constant squashing does not support prepared statements

er > interface doesn't change. > FWIW, i'm +1 on leaving it in pg18. Prepared statements often look a little different in other ways, and there are a bunch of other quirks in how queryid's are calculated too. Didn't there used to be something with CALL being hand

Re: queryId constant squashing does not support prepared statements

> On Thu, May 01, 2025 at 09:55:47PM GMT, Dmitry Dolgov wrote: > > On Thu, May 01, 2025 at 09:29:13AM GMT, Michael Paquier wrote: > > > > I agree that the current solution we have in the tree feels incomplete > > because we are not taking into account the most common cases that > > users would care

Re: queryId constant squashing does not support prepared statements

On 2025-May-02, Michael Paquier wrote: > That depends. If we conclude that tracking this information through > the parser based on the start and end positions in a query string > for a set of values is more relevant, then we would be redesigning the > facility from the ground, so the old approach

Re: queryId constant squashing does not support prepared statements

> On Fri, May 02, 2025 at 04:18:37PM GMT, Michael Paquier wrote: > On Fri, May 02, 2025 at 09:13:39AM +0200, Dmitry Dolgov wrote: > > Squashing constants was ment to be a first step towards doing the same > > for other types of queries (params, rte_values), reverting it to > > implement everything

Re: queryId constant squashing does not support prepared statements

On Fri, May 02, 2025 at 09:13:39AM +0200, Dmitry Dolgov wrote: > Squashing constants was ment to be a first step towards doing the same > for other types of queries (params, rte_values), reverting it to > implement everything at once makes very little sense to me. That depends. If we conclude tha

Re: queryId constant squashing does not support prepared statements

> On Fri, May 02, 2025 at 07:10:19AM GMT, Michael Paquier wrote: > > I am really leaning towards that we should revert this feature as the > > limitation we have now with parameters is a rather large one and I think > > we need to go back and address this issue. > > I am wondering if this would not

Re: queryId constant squashing does not support prepared statements

On Thu, May 01, 2025 at 03:57:16PM -0500, Sami Imseih wrote: > I think what we should really allow the broader scope of expressions that > are allowed via prepared statements, and this will make this implementation > consistent between prepared vs non-prepared statements. I don't see

Re: queryId constant squashing does not support prepared statements

eters are different in some way. I don't think limiting this feature to Const only will suffice. I think what we should really allow the broader scope of expressions that are allowed via prepared statements, and this will make this implementation consistent between prepared vs non-prepared statemen

Re: queryId constant squashing does not support prepared statements

> On Thu, May 01, 2025 at 09:29:13AM GMT, Michael Paquier wrote: > > I agree that the current solution we have in the tree feels incomplete > because we are not taking into account the most common cases that > users would care about. Now, allowing PARAM_EXTERN means that we > allow any expression

Re: queryId constant squashing does not support prepared statements

the IN-LIST. > > The patch lacks the ability to apply this optimization to values > passed in as parameters ( i.e. parameter kind = PARAM_EXTERN ) > which will be the case for SQL prepared statements and protocol level > prepared statements, i.e. > > I think this is a pre

queryId constant squashing does not support prepared statements

passed in as parameters ( i.e. parameter kind = PARAM_EXTERN ) which will be the case for SQL prepared statements and protocol level prepared statements, i.e. ``` select from t where id in (1, 2, 3) \bind ``` or ``` prepare prp(int, int, int) as select from t where id in ($1, $2, $3); ``` Here is

Re: Bug in pgbench prepared statements

On Fri, Dec 01, 2023 at 07:06:40PM -0800, Lev Kokotov wrote: > Attached. PR against master also here > , just to make sure it's > mergeable . Thanks for the updated patch. It looks sensible seen fr

Re: Bug in pgbench prepared statements

> The patch you have sent does not apply cleanly on the master branch, > could you rebase please? Attached. PR against master also here , just to make sure it's mergeable . > Wouldn't it > better t

Re: Bug in pgbench prepared statements

On Thu, Nov 30, 2023 at 07:15:54PM -0800, Lev Kokotov wrote: >> I see prepareCommand() is called one more time in >> prepareCommandsInPipeline(). Should you also check the return value >> there? > > Yes, good catch. New patch attached. Agreed that this is not really helpful as it stands >> It ma

Re: Bug in pgbench prepared statements

> I see prepareCommand() is called one more time in > prepareCommandsInPipeline(). Should you also check the return value > there? Yes, good catch. New patch attached. > It may also be useful to throw this patch on the January commitfest if > no one else comes along to review/commit it. First ti

Re: Bug in pgbench prepared statements

On Wed Nov 29, 2023 at 7:38 PM CST, Lev Kokotov wrote: Patch attached, if there is any interest in fixing this small bug. I see prepareCommand() is called one more time in prepareCommandsInPipeline(). Should you also check the return value there? It may also be useful to throw this patch on

Bug in pgbench prepared statements

Hi, I noticed something that looks like a bug in pgbench when using the prepared protocol. pgbench assumes that all prepared statements are prepared correctly, even if they contain errors (e.g. syntax, column/table doesn't exist, etc.). My test script is just: SELECT one; The output

Re: Deleting prepared statements from libpq.

On Tue, Jul 04, 2023 at 04:09:43PM +0900, Michael Paquier wrote: > On Tue, Jul 04, 2023 at 08:28:40AM +0900, Michael Paquier wrote: >> Sure, feel free. I was planning to look at and play more with it. > > Well, done. For the sake of completeness, as I forgot to send my notes. + if (PQsendClose

Re: Deleting prepared statements from libpq.

On Tue, Jul 04, 2023 at 08:28:40AM +0900, Michael Paquier wrote: > Sure, feel free. I was planning to look at and play more with it. Well, done. -- Michael signature.asc Description: PGP signature

Re: Deleting prepared statements from libpq.

On Mon, Jul 03, 2023 at 02:33:55PM +0200, Jelte Fennema wrote: > @Michael is anything else needed from my side? If not, I'll mark the > commitfest entry as "Ready For Committer". Sure, feel free. I was planning to look at and play more with it. -- Michael signature.asc Description: PGP signatur

Re: Deleting prepared statements from libpq.

@Michael is anything else needed from my side? If not, I'll mark the commitfest entry as "Ready For Committer".

Re: Deleting prepared statements from libpq.

On Fri, Jun 23, 2023 at 09:39:00AM +0200, Jelte Fennema wrote: > To be clear, it didn't actually change the behaviour. I only changed > the error message, since it said the exact opposite of what it was > expecting. I split this minor fix into its own commit now to clarify > that. I think it would

Re: Deleting prepared statements from libpq.

On Fri, 23 Jun 2023 at 05:59, Michael Paquier wrote: > [...] > res = PQgetResult(conn); > if (res == NULL) > - pg_fatal("expected NULL result"); > + pg_fatal("expected non-NULL result"); > > This should check for the NULL-ness of the result returned for > PQclosePrepared() rath

Re: Deleting prepared statements from libpq.

On Tue, Jun 20, 2023 at 01:42:13PM +0200, Jelte Fennema wrote: Thanks for updating the patch. > On Tue, 20 Jun 2023 at 06:18, Michael Paquier wrote: >> The amount of duplication between the describe and close paths >> concerns me a bit. Should PQsendClose() and PQsendDescribe() be >> merged int

Re: Deleting prepared statements from libpq.

On Tue, 20 Jun 2023 at 06:18, Michael Paquier wrote: > The amount of duplication between the describe and close paths > concerns me a bit. Should PQsendClose() and PQsendDescribe() be > merged into a single routine (say PQsendCommand), that uses a message > type for pqPutMsgStart and a queryclass

Re: Deleting prepared statements from libpq.

On Mon, Jun 19, 2023 at 02:49:44PM +0200, Jelte Fennema wrote: > On Mon, 19 Jun 2023 at 14:17, jian he wrote: >> I am not sure the following two following function comments are right > > They were incorrect indeed. Attached is a patch with those two updated. The amount of duplication between

Re: Deleting prepared statements from libpq.

ma wrote: > > > > On Mon, 19 Jun 2023 at 11:44, Jelte Fennema wrote: > > > Done > > > > Now with the actual attachment. > > > > PS. Another connection pooler (PgCat) now also supports prepared > > statements, but only using Close not DEALLOCATE

Re: Deleting prepared statements from libpq.

On Mon, Jun 19, 2023 at 5:50 PM Jelte Fennema wrote: > > On Mon, 19 Jun 2023 at 11:44, Jelte Fennema wrote: > > Done > > Now with the actual attachment. > > PS. Another connection pooler (PgCat) now also supports prepared > statements, but only using Cl

Re: Deleting prepared statements from libpq.

On Mon, 19 Jun 2023 at 11:44, Jelte Fennema wrote: > Done Now with the actual attachment. PS. Another connection pooler (PgCat) now also supports prepared statements, but only using Close not DEALLOCATE: https://postgresml.org/blog/making-postgres-30-percent-faster-in-production F

Re: Deleting prepared statements from libpq.

On Mon, 19 Jun 2023 at 04:52, jian he wrote: > > /* Now that it's closed we should get an error when describing */ > > res = PQdescribePortal(conn, "cursor_one"); > > if (PQresultStatus(res) != PGRES_FATAL_ERROR) > > pg_fatal("expected COMMAND_OK, got %s", PQresStatus(PQresultStatus(res))); > shou

Re: Deleting prepared statements from libpq.

On Mon, 19 Jun 2023 at 01:57, Michael Paquier wrote: > +static int > +PQsendClose(PGconn *conn, char close_type, const char *close_target) > > Could it be better for this code path to issue an error if using a > non-supported close_type rather than sending it? Okay, you are > consistent with desc

Re: Deleting prepared statements from libpq.

now it works. /src/test/modules/libpq_pipeline/libpq_pipeline.c > > /* Now that it's closed we should get an error when describing */ > res = PQdescribePortal(conn, "cursor_one"); > if (PQresultStatus(res) != PGRES_FATAL_ERROR) > pg_fatal("expected COMMAND_OK, got %s", PQresStatus(PQresultStatus(r

Re: Deleting prepared statements from libpq.

On Sun, Jun 18, 2023 at 01:03:57PM +0200, Jelte Fennema wrote: > Sorry about that. I attached a new patch that allows linking to the > new functions (I forgot to add the functions to exports.txt). This new > patch also adds some basic tests for these new functions. I am okay with the arguments abo

Re: Deleting prepared statements from libpq.

On Sun, Jun 18, 2023 at 09:23:22PM +0800, jian he wrote: > previously I cannot link it. with > v2-0001-Support-sending-Close-messages-from-libpq.patch. now I can > compile it, link it, but then run time error. > same c program in the first email. > when I run it ./a.out, then error: > ./a.out: symb

Re: Deleting prepared statements from libpq.

On Sun, Jun 18, 2023 at 7:04 PM Jelte Fennema wrote: > > On Sat, 17 Jun 2023 at 15:34, jian he wrote: > > I failed to link it. I don't know why. > > Sorry about that. I attached a new patch that allows linking to the > new functions (I forgot to add the functions to exports.txt). This new > patch

Re: Deleting prepared statements from libpq.

On Sat, 17 Jun 2023 at 15:34, jian he wrote: > I failed to link it. I don't know why. Sorry about that. I attached a new patch that allows linking to the new functions (I forgot to add the functions to exports.txt). This new patch also adds some basic tests for these new functions. v2-0001-Supp

Re: Deleting prepared statements from libpq.

On Fri, Jun 16, 2023 at 11:28 PM Jelte Fennema wrote: > > On Fri, 16 Jun 2023 at 16:26, Craig Ringer wrote: > > Nobody's implemented it. > > > > A patch to add PQclosePrepared and PQsendClosePrepared would be welcome. At > > least, I think so... > > This might have been a pretty old thread. But

Re: Deleting prepared statements from libpq.

On Fri, 16 Jun 2023 at 16:26, Craig Ringer wrote: > Nobody's implemented it. > > A patch to add PQclosePrepared and PQsendClosePrepared would be welcome. At > least, I think so... This might have been a pretty old thread. But I just took it upon me to implement these functions (or well I mostly

Re: MERGE and parsing with prepared statements

On 2022-Aug-12, Simon Riggs wrote: > Sorry, but I disagree with this chunk in the latest commit, > specifically, changing the MATCHED from after to before the NOT > MATCHED clause. > > The whole point of the second example was to demonstrate that the > order of the MATCHED/NOT MATCHED clauses mad

Re: MERGE and parsing with prepared statements

On Fri, Aug 12, 2022 at 01:53:25PM +0200, Alvaro Herrera wrote: > On 2022-Aug-12, Simon Riggs wrote: > > > Sorry, but I disagree with this chunk in the latest commit, > > specifically, changing the MATCHED from after to before the NOT > > MATCHED clause. 3d895bc84 also moved a semicolon into the

Re: MERGE and parsing with prepared statements

On 2022-Aug-12, Simon Riggs wrote: > Sorry, but I disagree with this chunk in the latest commit, > specifically, changing the MATCHED from after to before the NOT > MATCHED clause. > > The whole point of the second example was to demonstrate that the > order of the MATCHED/NOT MATCHED clauses mad

Re: MERGE and parsing with prepared statements

On Fri, 12 Aug 2022 at 12:20, Alvaro Herrera wrote: > On 2022-Jul-18, Justin Pryzby wrote: > > > On Fri, Jul 15, 2022 at 03:43:41PM -0500, Justin Pryzby wrote: > > > Should that sentence be removed from MERGE ? > > > > Also, I think these examples should be more similar. > > Agreed, done. Sorry,

Re: MERGE and parsing with prepared statements

On 2022-Jul-15, Justin Pryzby wrote: > Should that sentence be removed from MERGE ? Removed On 2022-Jul-18, Justin Pryzby wrote: > On Fri, Jul 15, 2022 at 03:43:41PM -0500, Justin Pryzby wrote: > > Should that sentence be removed from MERGE ? > > Also, I think these examples should be more sim

Re: MERGE and parsing with prepared statements

On Fri, Jul 15, 2022 at 03:43:41PM -0500, Justin Pryzby wrote: > Should that sentence be removed from MERGE ? Also, I think these examples should be more similar. doc/src/sgml/ref/merge.sgml > > MERGE INTO CustomerAccount CA > USING RecentTransactions T > ON T.CustomerId = CA.CustomerId > WHEN

Re: MERGE and parsing with prepared statements

On Fri, Jul 15, 2022 at 12:59:34PM -0700, David G. Johnston wrote: > On Fri, Jul 15, 2022 at 12:40 PM Justin Pryzby wrote: > > > > | If the expression for any column is not of the correct data type, automatic > type conversion will be attempted. > > That appears to be copied from the INSERT page

Re: MERGE and parsing with prepared statements

On Fri, Jul 15, 2022 at 12:40 PM Justin Pryzby wrote: > > That appears to be copied from the INSERT page. > What does that mean, if not that data types will be resolved as needed ? > Yep, and the system needs to resolve the type at a point where there is no contextual information and so it choos

Re: MERGE and parsing with prepared statements

bit odd that it's impossible to use merge with prepared > statements > > > > without specifically casting the source types (which I did now to > continue my > > > > experiment). > > > > > > I have no comments on this. Maybe it can be improved, bu

Re: MERGE and parsing with prepared statements

On Fri, Jul 15, 2022 at 12:17:51PM -0700, David G. Johnston wrote: > On Fri, Jul 15, 2022 at 11:40 AM Alvaro Herrera > wrote: > > On 2022-Jul-15, Justin Pryzby wrote: > > > > > It seems a bit odd that it's impossible to use merge with prepared > > > stat

Re: MERGE and parsing with prepared statements

On Fri, Jul 15, 2022 at 11:40 AM Alvaro Herrera wrote: > On 2022-Jul-15, Justin Pryzby wrote: > > > It seems a bit odd that it's impossible to use merge with prepared > statements > > without specifically casting the source types (which I did now to > continue my &

Re: MERGE and parsing with prepared statements

Alvaro Herrera writes: > On 2022-Jul-15, Justin Pryzby wrote: >> I see now that the same thing can happen with "ON CONFLICT" if used with a >> subselect. >> >> PREPARE p AS INSERT INTO t SELECT a FROM (SELECT $1 AS a)a >> ON CONFLICT (i) DO UPDATE SET i=excluded.i; >> ERROR: column "i" is of typ

Re: MERGE and parsing with prepared statements

ems a bit odd that it's impossible to use merge with prepared statements > without specifically casting the source types (which I did now to continue my > experiment). I have no comments on this. Maybe it can be improved, but I don't know how. -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/

Re: MERGE and parsing with prepared statements

same thing can happen with "ON CONFLICT" if used with a subselect. PREPARE p AS INSERT INTO t SELECT a FROM (SELECT $1 AS a)a ON CONFLICT (i) DO UPDATE SET i=excluded.i; ERROR: column "i" is of type integer but expression is of type text It seems a bit odd that it's i

Re: MERGE and parsing with prepared statements

On Thu, 14 Jul 2022, 18:26 Justin Pryzby, wrote: > > We've used INSERT ON CONFLICT for a few years (with partitions as the target). > That's also combined with prepared statements, for bulk loading. > > I was looking to see if we should use MERGE (probably not, but looki

MERGE and parsing with prepared statements

We've used INSERT ON CONFLICT for a few years (with partitions as the target). That's also combined with prepared statements, for bulk loading. I was looking to see if we should use MERGE (probably not, but looking anyway). And came across this behavior. I'm not sure if it'

Re: Improvements in prepared statements

ent side issue. It is about design of client side API. Pavel > El lun, 01-03-2021 a las 17:21 +0100, Pavel Stehule escribió: > > > > po 1. 3. 2021 v 17:15 odesílatel Pavel Stehule > napsal: > > > > po 1. 3. 2021 v 17:08 odesílatel Alejandro Sánchez > naps

Re: Improvements in prepared statements

napsal: > > po 1. 3. 2021 v 17:08 odesílatel Alejandro Sánchez < > > a...@nexttypes.com> napsal: > > > The benefit is ease of use. One of the great advantages of > > > prepared statements is nothaving to concatenate strings. The use > > > of arrays would also

Re: Improvements in prepared statements

I have already implemented this in my Java project with some kind of SQL preprocessor. I leave the idea here in case more people are interested and PostgreSQL developers findit convenient to include it. It is just string concatenation but it is a sintactic sugar very useful in any SQL application.

Re: Improvements in prepared statements

; El lun, 01-03-2021 a las 17:15 +0100, Pavel Stehule escribió: > > > > po 1. 3. 2021 v 17:08 odesílatel Alejandro Sánchez > napsal: > > The benefit is ease of use. O > > ne of the great advantages of prepared statements is not > > having to concatenate strings. The u

Re: Improvements in prepared statements

m> napsal: > > The benefit is ease of use. One of the great advantages of prepared > > statements is nothaving to concatenate strings. The use of arrays > > would also be very useful. > > query("select " + column1 + "," + column2 from " " + ta

Re: Improvements in prepared statements

po 1. 3. 2021 v 17:15 odesílatel Pavel Stehule napsal: > > > po 1. 3. 2021 v 17:08 odesílatel Alejandro Sánchez > napsal: > >> The benefit is ease of use. One of the great advantages of prepared >> statements is not >> >> having to concatenate string

Re: Improvements in prepared statements

po 1. 3. 2021 v 17:08 odesílatel Alejandro Sánchez napsal: > The benefit is ease of use. One of the great advantages of prepared > statements is not > > having to concatenate strings. The use of arrays would also be very useful. > > > query("select " + column1 +

Re: Improvements in prepared statements

The benefit is ease of use. One of the great advantages of prepared statements is nothaving to concatenate strings. The use of arrays would also be very useful. query("select " + column1 + "," + column2 from " " + table + " where id in (?), ids); VS

Re: Improvements in prepared statements

wiz&ved=0ahUKEwjp27mTto_vAhXR8uAKHUIjA5U4FBDh1QMIDA&uact=5>. > It would be nice if it was included in plain > > SQL. > > I am very sceptical about it. What benefit do you expect? When you cannot reuse an execution plan, then there is not any benefit of this. Then you don't

Re: Improvements in prepared statements

regards.Alejandro Sánchez. El lun, 01-03-2021 a las 15:31 +0100, Pavel Stehule escribió: > Hi > > po 1. 3. 2021 v 15:20 odesílatel Alejandro Sánchez < > a...@nexttypes.com> napsal: > > Hello, some improvements in the prepared statements would > > facilitate > &

Re: Improvements in prepared statements

Hi po 1. 3. 2021 v 15:20 odesílatel Alejandro Sánchez napsal: > Hello, some improvements in the prepared statements would facilitate > their use from applications: > > - Use of table and column names in prepared statements. > > Example: select # from # where # = ?; >

Improvements in prepared statements

Hello, some improvements in the prepared statements would facilitate their use from applications: - Use of table and column names in prepared statements. Example: select # from # where # = ?; - Use of arrays in prepared statements. Example: select # from article where id in

Re: [doc] adding way to examine the plan type of prepared statements

Hi Torikoshi-san, On Thu, Nov 19, 2020 at 3:19 PM torikoshia wrote: > > On 2020-11-18 11:04, torikoshia wrote: > > Hi, > > > > > > Currently, EXPLAIN is the only way to know whether the plan is generic > > or custom according to the manual of PREPARE. > > > > https://www.postgresql.org/docs/dev

Re: [doc] adding way to examine the plan type of prepared statements

EXECUTE name(parameter_values You can see all prepared statements available in the session by querying the pg_prepared_statements - system view. + system view. This view also shows the numbers of generic and custom plans + were chosen. -- 2.18.1

[doc] adding way to examine the plan type of prepared statements

Hi, Currently, EXPLAIN is the only way to know whether the plan is generic or custom according to the manual of PREPARE. https://www.postgresql.org/docs/devel/sql-prepare.html After commit d05b172, we can also use pg_prepared_statements view to examine the plan types. How about adding t

Re: Prepared Statements

EXECUTE statements do essentially the > same thing. > > In the server code, there is the plan cache. The plan cache tracks when > a plan needs to be invalidated and the query replanned. The handle to an > entry in the plan cache is a CachedPlanSource, which contains the SQL > orig

Re: Prepared Statements

the server code, there is the plan cache. The plan cache tracks when a plan needs to be invalidated and the query replanned. The handle to an entry in the plan cache is a CachedPlanSource, which contains the SQL original and enough information to (re-)plan the query as needed. The plan cache ha

Re: Prepared Statements

wing and consider sending any follow-up fresh to the -general list. The behavior would be specific to "your favorite language" so you should ask there. Client-side drivers can do lots of things besides interacting directly with the server. The docs for the server cover what facil

Prepared Statements

Hi, I am having a hard time pinning down which function creates a prepared statement. Say in some language I create a Prepared Statement and send it off. Before the first time I execute the prepared statement, which function is the one that 'creates' the prepared statement. In other words, which f

Re: Patch: New GUC prepared_statement_limit to limit memory used by prepared statements

On Tue, Sep 03, 2019 at 06:30:32PM -0400, Tom Lane wrote: > Oh ... actually, I bet the problem is that the patch thinks it's okay > to immediately free space in PlanCacheRelCallback and friends, rather > than just marking invalid entries as invalid. Nope, you cannot do that. > You can't tell wheth

Re: Patch: New GUC prepared_statement_limit to limit memory used by prepared statements

I wrote: > As far as the crash issue is concerned, I notice that right now the > cfbot is showing green for this patch, but that seems to just be because > the behavior is unstable. I see crashes in "make installcheck-parallel" > about 50% of the time with this patch applied. Since, in fact, > th

Re: Patch: New GUC prepared_statement_limit to limit memory used by prepared statements

Alvaro Herrera writes: > On this patch, beyond the fact that it's causing a crash in the > regression tests as evidenced by the CFbot, we seem to be waiting on the > input of the larger community on whether it's a desired feature or not. > We have Kyotaro's vote for it, but it would be good to get

Re: Patch: New GUC prepared_statement_limit to limit memory used by prepared statements

On 2019-Aug-18, Daniel Migowski wrote: > >  - Is this a WIP patch or the final patch? Because I can see TODO > > and non-standard comments in the patch. > > Definitely work in progress! The current implementation seems to work for > me, but might be improved, but I wanted some input from the mail

Re: Patch: New GUC prepared_statement_limit to limit memory used by prepared statements

Am 19.08.2019 um 05:57 schrieb Kyotaro Horiguchi: At Sun, 18 Aug 2019 09:43:09 +0200, Daniel Migowski wrote in <6e25ca12-9484-8994-a1ee-40fdbe6af...@ikoffice.de> Am 17.08.2019 um 19:10 schrieb Ibrar Ahmed: On Sat, Aug 17, 2019 at 6:58 PM Daniel Migowski mailto:dmigow...@ikoffice.de>> wrote:

Re: Patch: New GUC prepared_statement_limit to limit memory used by prepared statements

age, which would be too expensive for the purpose. We currently use it only for debug output on critical errors like OOM. > No, it is a proposal. It could also be named plancache_mem or > cachedplansource_maxmem or anything else. It was intended to make > prepared statements not use up all my m

Re: Patch: New GUC prepared_statement_limit to limit memory used by prepared statements

sus about the name of GUC? I don't think it is the right name for that. No, it is a proposal. It could also be named plancache_mem or cachedplansource_maxmem or anything else. It was intended to make prepared statements not use up all my mem, but development has shown that it could also be

Re: Patch: New GUC prepared_statement_limit to limit memory used by prepared statements

ects > the maximum memory > a backend threads will reserve when many prepared statements > are used. > The default value of 0 disables this setting, but it is > recommended to set this > value to a bit lower than the maximum memory a backend worker > thre

Patch: New GUC prepared_statement_limit to limit memory used by prepared statements

many prepared statements are used.     The default value of 0 disables this setting, but it is recommended to set this     value to a bit lower than the maximum memory a backend worker thread should reserve     permanently. If the GUC is configured after each save of a

  1   2   >