On Tue, Oct 11, 2022 at 11:54:51AM +0900, Michael Paquier wrote:
> On Mon, Oct 10, 2022 at 09:16:47PM +0800, Julien Rouhaud wrote:
>> Unless I'm missing something both can be handled using pg_node_attr()
>> annotations that already exists?
>
> Indeed, that should work for the locators.
My mistake
On Wed, Oct 12, 2022 at 09:13:20AM +0900, Michael Paquier wrote:
> Thanks for mentioning that. With an automated way to generate this
> code, cursors would be handled, at the advantage of making sure that
> no fields are missing in the jumbled structures (is_local was missed
> for example on SET).
On Tue, Oct 11, 2022 at 02:18:54PM +, Imseih (AWS), Sami wrote:
> +1 to the idea, as there are other utility statement cases
> that should be Jumbled. Here is a recent thread for jumbling
> cursors [1].
Thanks for mentioning that. With an automated way to generate this
code, cursors would be
> I've been thinking since the beginning of this thread that there
> was no coherent, defensible rationale being offered for jumbling
> some utility statements and not others.
+1 to the idea, as there are other utility statement cases
that should be Jumbled. Here is a recent thread for jumbling
cu
On Mon, Oct 10, 2022 at 09:16:47PM +0800, Julien Rouhaud wrote:
> Unless I'm missing something both can be handled using pg_node_attr()
> annotations that already exists?
Indeed, that should work for the locators.
--
Michael
signature.asc
Description: PGP signature
Hi,
On Mon, Oct 10, 2022 at 03:04:57PM +0200, Drouvot, Bertrand wrote:
>
> On 10/7/22 6:13 AM, Michael Paquier wrote:
> >
> > Probably. One part that may be tricky though is the location of the
> > constants we'd like to make generic, but perhaps this could be handled
> > by using a dedicated var
Hi,
On 10/7/22 6:13 AM, Michael Paquier wrote:
On Thu, Oct 06, 2022 at 11:51:52PM -0400, Tom Lane wrote:
I've been thinking since the beginning of this thread that there
was no coherent, defensible rationale being offered for jumbling
some utility statements and not others.
Yeah. The potenti
On Thu, Oct 06, 2022 at 11:51:52PM -0400, Tom Lane wrote:
> Michael Paquier writes:
> > While studying a bit more this thread, I've been reminded of the fact
> > that this would treat different flavors of BEGIN/COMMIT commands (mix
> > of upper/lower characters, etc.) as different entries in
> > p
On Thu, Oct 06, 2022 at 11:51:52PM -0400, Tom Lane wrote:
> I've been thinking since the beginning of this thread that there
> was no coherent, defensible rationale being offered for jumbling
> some utility statements and not others.
Yeah. The potential performance impact of all the TransactionSt
Michael Paquier writes:
> While studying a bit more this thread, I've been reminded of the fact
> that this would treat different flavors of BEGIN/COMMIT commands (mix
> of upper/lower characters, etc.) as different entries in
> pg_stat_statements, and it feels inconsistent to me that we'd begin
On Thu, Oct 06, 2022 at 10:43:57AM +0200, Drouvot, Bertrand wrote:
> On 10/6/22 8:39 AM, Michael Paquier wrote:
>> I am not seeing SAVEPOINT, RELEASE, ROLLBACK .. TO SAVEPOINT
>> mentioned on this thread. Would these be worth considering in what
>> gets compiled? That would cover the remaining bi
Hi,
On 10/6/22 8:39 AM, Michael Paquier wrote:
On Mon, Sep 19, 2022 at 08:29:22AM +0200, Drouvot, Bertrand wrote:
Please find attached v6 taking care of the remarks mentioned above.
+case T_VariableSetStmt:
+{
+VariableSetStmt *stmt = (VariableSetStmt *) node
Hi,
On 9/26/22 12:40 PM, Drouvot, Bertrand wrote:
let's add it in V7 attached
(that's safer should the code change later on).
Attached a tiny rebase needed due to 249b0409b1.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.
On Mon, Sep 19, 2022 at 08:29:22AM +0200, Drouvot, Bertrand wrote:
> Please find attached v6 taking care of the remarks mentioned above.
> +case T_VariableSetStmt:
> +{
> +VariableSetStmt *stmt = (VariableSetStmt *) node;
> +
> +/* stmt->name is N
Hi,
On 9/21/22 6:07 PM, Fujii Masao wrote:
On 2022/09/19 15:29, Drouvot, Bertrand wrote:
Please find attached v6 taking care of the remarks mentioned above.
Thanks for updating the patch!
+SET pg_stat_statements.track_utility = TRUE;
+
+-- PL/pgSQL procedure and pg_stat_statements.track =
On 2022/09/19 15:29, Drouvot, Bertrand wrote:
Please find attached v6 taking care of the remarks mentioned above.
Thanks for updating the patch!
+SET pg_stat_statements.track_utility = TRUE;
+
+-- PL/pgSQL procedure and pg_stat_statements.track = all
+-- we drop and recreate the procedures
Hi,
On 9/16/22 5:47 PM, Drouvot, Bertrand wrote:
Hi,
On 9/16/22 2:53 PM, Fujii Masao wrote:
Attached v5 to normalize 2PC commands too, so that we get things like:
+ case T_VariableSetStmt:
+ {
+ VariableSetStmt *stmt = (VariableSetStmt *) node;
+
+
Hi,
On 9/16/22 2:53 PM, Fujii Masao wrote:
Attached v5 to normalize 2PC commands too, so that we get things like:
+ case T_VariableSetStmt:
+ {
+ VariableSetStmt *stmt = (VariableSetStmt *) node;
+
+ /* stmt->name is NULL for RESET ALL */
+
>The utility commands for cursor like DECLARE CURSOR seem to have the same
> issue
>and can cause lots of pgss entries. For example, when we use postgres_fdw
> and
>execute "SELECT * FROM WHERE id = 10" five times in the
> same
>transaction, the following commands are executed i
On 2022/09/09 19:11, Drouvot, Bertrand wrote:
IME if your application relies on 2PC it's very likely that you will hit the
exact same problems described in your original email.
The utility commands for cursor like DECLARE CURSOR seem to have the same issue
and can cause lots of pgss entries.
Hi,
On 9/13/22 6:33 AM, Julien Rouhaud wrote:
Hi,
On Tue, Sep 13, 2022 at 11:43:52AM +0900, bt22kawamotok wrote:
I found that utility statement is counted separately in upper and lower
case.
For example BEGIN and begin are counted separately.
Is it difficult to fix this problem?
This is a kno
Hi,
On Tue, Sep 13, 2022 at 11:43:52AM +0900, bt22kawamotok wrote:
>
> I found that utility statement is counted separately in upper and lower
> case.
> For example BEGIN and begin are counted separately.
> Is it difficult to fix this problem?
This is a known behavior, utility command aren't norm
Attached v5 to normalize 2PC commands too, so that we get things like:
create table test_tx (a int);
begin;
prepare transaction 'tx1';
insert into test_tx values (1);
commit prepared 'tx1';
begin;
prepare transaction 'tx2';
insert into test_tx values (2);
commit prepared 'tx2';
begin;
prepare tr
23 matches
Mail list logo
