pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgsql: Do not show information_schema in \d* commands, unless 'S' or
3+ messages / 2 participants
[nested] [flat]
* pgsql: Do not show information_schema in \d* commands, unless 'S' or
@ 2009-04-02 17:38 Bruce Momjian <momjian@postgresql.org>
0 siblings, 0 replies; 3+ messages in thread
From: momjian@postgresql.org @ 2009-04-02 17:38 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Do not show information_schema in \d* commands, unless 'S' or pattern is
specified.
Martin Pihlak
Modified Files:
--------------
pgsql/src/bin/psql:
describe.c (r1.204 -> r1.205)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/describe.c?r1=1.204&r2=1.205)
^ permalink raw reply [nested|flat] 3+ messages in thread
* pgsql: Use a hash table for catcache.c's CatCList objects.
@ 2024-03-22 21:14 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 3+ messages in thread
From: Tom Lane @ 2024-03-22 21:14 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Use a hash table for catcache.c's CatCList objects.
Up to now, all of the "catcache list" objects within a catalog cache
were just chained together on a single dlist, requiring O(N) time to
search. Remarkably, we've not had serious performance problems with
that so far; but we got a complaint of a bad performance regression
from v15 in a case with a large number of roles in the system, which
traced down to O(N^2) total time when we probed N catcache lists.
Replace that data structure with a hashtable having an enlargeable
number of dlists, in an exactly parallel way to the data structure
we've used for years for the plain CatCTup cache members. The extra
cost of maintaining a hash table seems negligible, since we were
already computing a hash value for list searches.
Normally this'd be HEAD-only material, but in view of the performance
regression it seems advisable to back-patch into v16. In the v16
version of the patch, leave the dead cc_lists field where it is and
add the new fields at the end of struct catcache, to avoid possible
ABI breakage in case any external code is looking at these structs.
(We assume no external code is actually allocating new catcache
structs.)
Per report from alex work.
Discussion: https://postgr.es/m/CAGvXd3OSMbJQwOSc-Tq-Ro1CAz=vggErdSG7pv2s6vmmTOLJSg@mail.gmail.com
Branch
------
REL_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/14e991db89b1e0fd39e8875b80da7f0b0c3533a4
Modified Files
--------------
src/backend/utils/cache/catcache.c | 143 +++++++++++++++++++++++++++++++------
src/include/utils/catcache.h | 5 ++
2 files changed, 125 insertions(+), 23 deletions(-)
^ permalink raw reply [nested|flat] 3+ messages in thread
* pgsql: Use a hash table for catcache.c's CatCList objects.
@ 2024-03-22 21:14 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 3+ messages in thread
From: Tom Lane @ 2024-03-22 21:14 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Use a hash table for catcache.c's CatCList objects.
Up to now, all of the "catcache list" objects within a catalog cache
were just chained together on a single dlist, requiring O(N) time to
search. Remarkably, we've not had serious performance problems with
that so far; but we got a complaint of a bad performance regression
from v15 in a case with a large number of roles in the system, which
traced down to O(N^2) total time when we probed N catcache lists.
Replace that data structure with a hashtable having an enlargeable
number of dlists, in an exactly parallel way to the data structure
we've used for years for the plain CatCTup cache members. The extra
cost of maintaining a hash table seems negligible, since we were
already computing a hash value for list searches.
Normally this'd be HEAD-only material, but in view of the performance
regression it seems advisable to back-patch into v16. In the v16
version of the patch, leave the dead cc_lists field where it is and
add the new fields at the end of struct catcache, to avoid possible
ABI breakage in case any external code is looking at these structs.
(We assume no external code is actually allocating new catcache
structs.)
Per report from alex work.
Discussion: https://postgr.es/m/CAGvXd3OSMbJQwOSc-Tq-Ro1CAz=vggErdSG7pv2s6vmmTOLJSg@mail.gmail.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/473182c9523afad10e9507145690d902a0bc7f04
Modified Files
--------------
src/backend/utils/cache/catcache.c | 143 +++++++++++++++++++++++++++++++------
src/include/utils/catcache.h | 6 +-
2 files changed, 124 insertions(+), 25 deletions(-)
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-03-22 21:14 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-04-02 17:38 pgsql: Do not show information_schema in \d* commands, unless 'S' or Bruce Momjian <momjian@postgresql.org>
2024-03-22 21:14 pgsql: Use a hash table for catcache.c's CatCList objects. Tom Lane <tgl@sss.pgh.pa.us>
2024-03-22 21:14 pgsql: Use a hash table for catcache.c's CatCList objects. Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox