Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sql: investigate composite type introspection slowness #121225

Open
annrpom opened this issue Mar 27, 2024 · 2 comments
Open

sql: investigate composite type introspection slowness #121225

annrpom opened this issue Mar 27, 2024 · 2 comments
Assignees
Labels
A-sql-pgcatalog C-performance Perf of queries or internals. Solution not expected to change functional behavior. T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions)

Comments

@annrpom
Copy link
Contributor

annrpom commented Mar 27, 2024

Repro:

demo@127.0.0.1:26257/demoapp/movr> create type t as (foo int, bar int);                                                    
CREATE TYPE

Time: 5ms total (execution 5ms / network 0ms)

demo@127.0.0.1:26257/demoapp/movr> select attrelid::regclass, attname, atttypid::regtype, attnum from pg_attribute where   
                                -> attrelid = 't'::regclass;                                                               
  attrelid | attname | atttypid | attnum
-----------+---------+----------+---------
  t        | foo     | int8     |      1
  t        | bar     | int8     |      2
(2 rows)

Time: 15.917s total (execution 15.917s / network 0.000s)

Observe the 15.917s total latency on the introspection query

However, if we lookup t's oid via the pg_type table (cast to regtype instead of regclass), we get what we expect:

demo@127.0.0.1:26257/demoapp/movr> select attrelid::regclass, attname, atttypid::regtype, attnum from pg_attribute where   
                                -> attrelid = 't'::regtype;                                                                
  attrelid | attname | atttypid | attnum
-----------+---------+----------+---------
  t        | foo     | int8     |      1
  t        | bar     | int8     |      2
(2 rows)

Time: 7ms total (execution 6ms / network 0ms)

So it looks like pg_type is good - something in pg_class is likely the problem.

While we are here, we can see/keep track of how many round trips the query does by adding this to rttanalysis tests.

Jira issue: CRDB-37145

@annrpom annrpom added C-performance Perf of queries or internals. Solution not expected to change functional behavior. T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions) labels Mar 27, 2024
@annrpom annrpom self-assigned this Mar 27, 2024
@blathers-crl blathers-crl bot added this to Triage in SQL Foundations Mar 27, 2024
@fqazi
Copy link
Collaborator

fqazi commented Apr 9, 2024

@annrpom Did this come from a support escalation? If it did can we add the tags on this issue for that

@annrpom
Copy link
Contributor Author

annrpom commented Apr 9, 2024

It did not @fqazi 🙇

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-sql-pgcatalog C-performance Perf of queries or internals. Solution not expected to change functional behavior. T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions)
Projects
SQL Foundations
  
Triage
Development

No branches or pull requests

2 participants