public inbox for [email protected]
help / color / mirror / Atom feed[PATCH 2/3] Allow composite types in bootstrap
5+ messages / 3 participants
[nested] [flat]
* [PATCH 2/3] Allow composite types in bootstrap
@ 2020-11-17 15:28 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 5+ messages in thread
From: Justin Pryzby @ 2020-11-17 15:28 UTC (permalink / raw)
---
src/backend/bootstrap/bootstrap.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/src/backend/bootstrap/bootstrap.c b/src/backend/bootstrap/bootstrap.c
index 18eb62ca47..e4fc75ab84 100644
--- a/src/backend/bootstrap/bootstrap.c
+++ b/src/backend/bootstrap/bootstrap.c
@@ -916,6 +916,7 @@ gettype(char *type)
{
if (Typ != NIL)
{
+ static bool did_reread PG_USED_FOR_ASSERTS_ONLY = false; /* Already reread pg_types */
ListCell *lc;
foreach (lc, Typ)
@@ -927,6 +928,33 @@ gettype(char *type)
return app->am_oid;
}
}
+
+ /*
+ * The type wasn't known; check again to handle composite
+ * types, added since first populating the array.
+ */
+
+ /*
+ * Once all the types are populated and we handled composite
+ * types, shouldn't need to do that again.
+ */
+ Assert(!did_reread);
+ did_reread = true;
+
+ list_free_deep(Typ);
+ Typ = NULL;
+ populate_typ_array();
+
+ /* Need to avoid infinite recursion... */
+ foreach (lc, Typ)
+ {
+ struct typmap *app = lfirst(lc);
+ if (strncmp(NameStr(app->am_typ.typname), type, NAMEDATALEN) == 0)
+ {
+ Ap = app;
+ return app->am_oid;
+ }
+ }
}
else
{
--
2.26.2
--------------9399ACFA5093E21681352885
Content-Type: text/x-patch; charset=UTF-8;
name="0003-Extended-statistics-on-expressions-20210117.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="0003-Extended-statistics-on-expressions-20210117.patch"
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: pg_stat_statements and "IN" conditions
@ 2025-02-11 12:14 Álvaro Herrera <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Álvaro Herrera @ 2025-02-11 12:14 UTC (permalink / raw)
To: Dmitry Dolgov <[email protected]>; +Cc: Kirill Reshke <[email protected]>; Sergei Kornilov <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; pgsql-hackers; [email protected]; Sutou Kouhei <[email protected]>
Hello
I noticed something that surprised me at first, but on further looking
it should have been obvious: setting pg_stat_statements.query_id_const_merge
affects the query ID for all readers of it, not just pg_stat_statement.
This is good because it preserves the property that pg_stat_activity
entries can be matched to pg_stat_statement entries by query_id.
Looking to commit 0001 soon.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"On the other flipper, one wrong move and we're Fatal Exceptions"
(T.U.X.: Term Unit X - http://www.thelinuxreview.com/TUX/)
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: pg_stat_statements and "IN" conditions
@ 2025-02-11 16:49 Sami Imseih <[email protected]>
parent: Álvaro Herrera <[email protected]>
0 siblings, 2 replies; 5+ messages in thread
From: Sami Imseih @ 2025-02-11 16:49 UTC (permalink / raw)
To: Álvaro Herrera <[email protected]>; +Cc: Dmitry Dolgov <[email protected]>; Kirill Reshke <[email protected]>; Sergei Kornilov <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; pgsql-hackers; [email protected]; Sutou Kouhei <[email protected]>
I have only looked at 0001, but I am wondering why
query_id_const_merge is a pg_stat_statements GUC
rather than a core GUC?
The dependency of pg_stat_statements to take advantage
of this useful feature does not seem right.
For example if the user does not have pg_stat_statements enabled,
but are sampling top queryId from pg_stat_activity, they will
likely want this merge behavior to build meaningful database
load graphs.
Other extensions that consume queryIds may also want this
behavior without needing to enable pg_stat_statements.
Also, we have compute_query_id as a core parameter, this
new guc will become an option for how to compute a queryId.
In the future we may want to introduce other controls for how a
queryId is generated.
Regards,
Sami
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: pg_stat_statements and "IN" conditions
@ 2025-02-11 18:00 Sami Imseih <[email protected]>
parent: Sami Imseih <[email protected]>
1 sibling, 0 replies; 5+ messages in thread
From: Sami Imseih @ 2025-02-11 18:00 UTC (permalink / raw)
To: Álvaro Herrera <[email protected]>; +Cc: Dmitry Dolgov <[email protected]>; Kirill Reshke <[email protected]>; Sergei Kornilov <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; pgsql-hackers; [email protected]; Sutou Kouhei <[email protected]>
I do not have an explanation from the patch yet, but I have a test
that appears to show unexpected results. I only tested a few datatypes,
but from what I observe, some merge as expected and others do not;
i.e. int columns merge correctly but bigint do not.
"""
show pg_stat_statements.query_id_const_merge ;
create table foo (col_int int, col_smallint smallint, col_bigint
bigint, col_float float, col_text text, col_varchar varchar);
select from foo where col_int in (1, 2, 3);
select from foo where col_int in (1, 2, 3, 4);
select from foo where col_int in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
select from foo where col_smallint in (1, 2, 3);
select from foo where col_smallint in (1, 2, 3, 4);
select from foo where col_bigint in (1, 2, 3);
select from foo where col_bigint in (1, 2, 3, 4);
select from foo where col_bigint in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
select from foo where col_float in (1, 2, 3);
select from foo where col_float in (1, 2, 3, 4);
select query, queryid, calls from pg_stat_statements where query like
'select from foo where%' order by 1 desc ;
"""
postgres=# show pg_stat_statements.query_id_const_merge ;
pg_stat_statements.query_id_const_merge
-----------------------------------------
on
(1 row)
....
.......
..........
postgres=# select query, queryid, calls from pg_stat_statements where
query like 'select from foo where%' order by 1 desc ;
query
| queryid | calls
-------------------------------------------------------------------------------+----------------------+-------
select from foo where col_smallint in (...)
| -2065640271713949220 | 2
select from foo where col_int in (...)
| 2911888824129257715 | 3
select from foo where col_float in ($1, $2, $3, $4)
| -6847088148705359339 | 1
select from foo where col_float in ($1, $2, $3)
| 1631437678183488606 | 1
select from foo where col_bigint in ($1, $2, $3, $4, $5, $6, $7, $8,
$9, $10) | 3174053975478689499 | 1
select from foo where col_bigint in ($1, $2, $3, $4)
| -5236067031911646410 | 1
select from foo where col_bigint in ($1, $2, $3)
| -5529594240898645457 | 1
(7 rows)
---
Sami
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: pg_stat_statements and "IN" conditions
@ 2025-02-11 18:52 Álvaro Herrera <[email protected]>
parent: Sami Imseih <[email protected]>
1 sibling, 0 replies; 5+ messages in thread
From: Álvaro Herrera @ 2025-02-11 18:52 UTC (permalink / raw)
To: Sami Imseih <[email protected]>; +Cc: Dmitry Dolgov <[email protected]>; Kirill Reshke <[email protected]>; Sergei Kornilov <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; pgsql-hackers; [email protected]; Sutou Kouhei <[email protected]>
On 2025-Feb-11, Sami Imseih wrote:
> I have only looked at 0001, but I am wondering why
> query_id_const_merge is a pg_stat_statements GUC
> rather than a core GUC?
I was wondering the same thing and found the explanation
here:
https://postgr.es/m/[email protected]
> Other extensions that consume queryIds may also want this
> behavior without needing to enable pg_stat_statements.
I agree. In fact, pg_stat_activity will behave differently (using
merged query_ids) if this value is turned on, for which you need the
contrib module. This makes no sense to me.
Besides, the patch cheats in this regard: what Dmitry did was
create a function SetQueryIdConstMerge() which the extension with the
GUC can call to set the value of the variable. I really don't see that
this is better. I think we should put the GUC back where it was in v15
of the patch. (I didn't check what other changes there were
afterwards.)
About the GUC name -- query_id_const_merge -- I think this is too much a
hacker's name. How about
query_id_merge_values
query_id_merge_value_lists
query_id_squash_constant_lists
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"No es bueno caminar con un hombre muerto"
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2025-02-11 18:52 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-11-17 15:28 [PATCH 2/3] Allow composite types in bootstrap Justin Pryzby <[email protected]>
2025-02-11 12:14 Re: pg_stat_statements and "IN" conditions Álvaro Herrera <[email protected]>
2025-02-11 16:49 ` Re: pg_stat_statements and "IN" conditions Sami Imseih <[email protected]>
2025-02-11 18:00 ` Re: pg_stat_statements and "IN" conditions Sami Imseih <[email protected]>
2025-02-11 18:52 ` Re: pg_stat_statements and "IN" conditions Álvaro Herrera <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox