public inbox for [email protected]help / color / mirror / Atom feed
[PATCH 2/3] Allow composite types in bootstrap 3+ 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; 3+ 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 --------------8FD28E9B65A94BB176003065 Content-Type: text/x-patch; charset=UTF-8; name="0003-Extended-statistics-on-expressions-20210116.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0003-Extended-statistics-on-expressions-20210116.patch" ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: psql: Greatly speed up "\d tablename" when not using regexes @ 2024-04-10 18:31 Jelte Fennema-Nio <[email protected]> 2024-04-10 20:11 ` Re: psql: Greatly speed up "\d tablename" when not using regexes Tom Lane <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Jelte Fennema-Nio @ 2024-04-10 18:31 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: pgsql-hackers On Wed, 10 Apr 2024 at 20:06, Tom Lane <[email protected]> wrote: > Really? ISTM this argument is ignoring an optimization the backend > has understood for a long time. Interesting. I didn't know about that optimization. I can't check right now, but probably the COLLATE breaks that optimization. ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: psql: Greatly speed up "\d tablename" when not using regexes 2024-04-10 18:31 Re: psql: Greatly speed up "\d tablename" when not using regexes Jelte Fennema-Nio <[email protected]> @ 2024-04-10 20:11 ` Tom Lane <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Tom Lane @ 2024-04-10 20:11 UTC (permalink / raw) To: Jelte Fennema-Nio <[email protected]>; +Cc: pgsql-hackers Jelte Fennema-Nio <[email protected]> writes: > On Wed, 10 Apr 2024 at 20:06, Tom Lane <[email protected]> wrote: >> Really? ISTM this argument is ignoring an optimization the backend >> has understood for a long time. > Interesting. I didn't know about that optimization. I can't check > right now, but probably the COLLATE breaks that optimization. Not for me. # explain select * from pg_class where relname ~ '^(foo)$' collate "en_US"; QUERY PLAN --------------------------------------------------------------------------------------------- Index Scan using pg_class_relname_nsp_index on pg_class (cost=0.27..8.29 rows=1 width=263) Index Cond: (relname = 'foo'::text) Filter: (relname ~ '^(foo)$'::text COLLATE "en_US") (3 rows) Also, using -E: # \d foo /******** QUERY *********/ SELECT c.oid, n.nspname, c.relname FROM pg_catalog.pg_class c LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace WHERE c.relname OPERATOR(pg_catalog.~) '^(foo)$' COLLATE pg_catalog.default AND pg_catalog.pg_table_is_visible(c.oid) ORDER BY 2, 3; /************************/ # explain SELECT c.oid, n.nspname, c.relname FROM pg_catalog.pg_class c LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace WHERE c.relname OPERATOR(pg_catalog.~) '^(foo)$' COLLATE pg_catalog.default AND pg_catalog.pg_table_is_visible(c.oid) ORDER BY 2, 3; QUERY PLAN ---------------------------------------------------------------------------------------------------------- Sort (cost=9.42..9.42 rows=1 width=132) Sort Key: n.nspname, c.relname -> Nested Loop Left Join (cost=0.27..9.41 rows=1 width=132) Join Filter: (n.oid = c.relnamespace) -> Index Scan using pg_class_relname_nsp_index on pg_class c (cost=0.27..8.32 rows=1 width=72) Index Cond: (relname = 'foo'::text) Filter: ((relname ~ '^(foo)$'::text) AND pg_table_is_visible(oid)) -> Seq Scan on pg_namespace n (cost=0.00..1.04 rows=4 width=68) (8 rows) There may be an argument for psql to do what you suggest, but so far it seems like duplicative complication. If there's a case you can demonstrate where "\d foo" doesn't optimize into an indexscan, we should look into exactly why that's happening, because I think the cause must be more subtle than this. regards, tom lane ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-04-10 20:11 UTC | newest] Thread overview: 3+ 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]> 2024-04-10 18:31 Re: psql: Greatly speed up "\d tablename" when not using regexes Jelte Fennema-Nio <[email protected]> 2024-04-10 20:11 ` Re: psql: Greatly speed up "\d tablename" when not using regexes Tom Lane <[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