Re: Improving information_schema._pg_expandarray()
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2023-12-23T18:27:18Z
Lists: pgsql-hackers
so 23. 12. 2023 v 19:18 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal: > I happened to notice that information_schema._pg_expandarray(), > which has the nigh-unreadable definition > > AS 'select $1[s], > s operator(pg_catalog.-) pg_catalog.array_lower($1,1) > operator(pg_catalog.+) 1 > from pg_catalog.generate_series(pg_catalog.array_lower($1,1), > pg_catalog.array_upper($1,1), > 1) as g(s)'; > > can now be implemented using unnest(): > > AS 'SELECT * FROM pg_catalog.unnest($1) WITH ORDINALITY'; > > It seems to be slightly more efficient this way, but the main point > is to make it more readable. > > I then realized that we could also borrow unnest's infrastructure > for rowcount estimation: > > ROWS 100 SUPPORT pg_catalog.array_unnest_support > > because array_unnest_support just looks at the array argument and > doesn't have any hard dependency on the function being specifically > unnest(). I'm not sure that any of its uses in information_schema > can benefit from that right now, but surely it can't hurt. > > One minor annoyance is that psql.sql is using _pg_expandarray > as a test case for \sf[+]. While we could keep doing so, I think > the main point of that test case is to exercise \sf+'s line > numbering ability, so the new one-line body is not a great test. > I changed that test to use _pg_index_position instead. > +1 regards Pavel > regards, tom lane > >
Commits
-
Improve the implementation of information_schema._pg_expandarray().
- 58054de2d084 17.0 landed