public inbox for [email protected]help / color / mirror / Atom feed
[PATCH 1/3] bootstrap: convert Typ to a List* 3+ messages / 3 participants [nested] [flat]
* [PATCH 1/3] bootstrap: convert Typ to a List* @ 2020-11-20 02:48 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Justin Pryzby @ 2020-11-20 02:48 UTC (permalink / raw) --- src/backend/bootstrap/bootstrap.c | 69 ++++++++++++++----------------- 1 file changed, 31 insertions(+), 38 deletions(-) diff --git a/src/backend/bootstrap/bootstrap.c b/src/backend/bootstrap/bootstrap.c index 6f615e6622..18eb62ca47 100644 --- a/src/backend/bootstrap/bootstrap.c +++ b/src/backend/bootstrap/bootstrap.c @@ -159,7 +159,7 @@ struct typmap FormData_pg_type am_typ; }; -static struct typmap **Typ = NULL; +static List *Typ = NIL; /* List of struct typmap* */ static struct typmap *Ap = NULL; static Datum values[MAXATTR]; /* current row's attribute values */ @@ -597,7 +597,7 @@ boot_openrel(char *relname) * pg_type must be filled before any OPEN command is executed, hence we * can now populate the Typ array if we haven't yet. */ - if (Typ == NULL) + if (Typ == NIL) populate_typ_array(); if (boot_reldesc != NULL) @@ -688,7 +688,7 @@ DefineAttr(char *name, char *type, int attnum, int nullness) typeoid = gettype(type); - if (Typ != NULL) + if (Typ != NIL) { attrtypes[attnum]->atttypid = Ap->am_oid; attrtypes[attnum]->attlen = Ap->am_typ.typlen; @@ -877,36 +877,25 @@ populate_typ_array(void) Relation rel; TableScanDesc scan; HeapTuple tup; - int nalloc; - int i; - - Assert(Typ == NULL); - nalloc = 512; - Typ = (struct typmap **) - MemoryContextAlloc(TopMemoryContext, nalloc * sizeof(struct typmap *)); + Assert(Typ == NIL); rel = table_open(TypeRelationId, NoLock); scan = table_beginscan_catalog(rel, 0, NULL); - i = 0; while ((tup = heap_getnext(scan, ForwardScanDirection)) != NULL) { Form_pg_type typForm = (Form_pg_type) GETSTRUCT(tup); + struct typmap *newtyp; + MemoryContext old; - /* make sure there will be room for a trailing NULL pointer */ - if (i >= nalloc - 1) - { - nalloc *= 2; - Typ = (struct typmap **) - repalloc(Typ, nalloc * sizeof(struct typmap *)); - } - Typ[i] = (struct typmap *) - MemoryContextAlloc(TopMemoryContext, sizeof(struct typmap)); - Typ[i]->am_oid = typForm->oid; - memcpy(&(Typ[i]->am_typ), typForm, sizeof(Typ[i]->am_typ)); - i++; + old = MemoryContextSwitchTo(TopMemoryContext); + newtyp = (struct typmap *) palloc(sizeof(struct typmap)); + Typ = lappend(Typ, newtyp); + MemoryContextSwitchTo(old); + + newtyp->am_oid = typForm->oid; + memcpy(&newtyp->am_typ, typForm, sizeof(newtyp->am_typ)); } - Typ[i] = NULL; /* Fill trailing NULL pointer */ table_endscan(scan); table_close(rel, NoLock); } @@ -925,16 +914,17 @@ populate_typ_array(void) static Oid gettype(char *type) { - if (Typ != NULL) + if (Typ != NIL) { - struct typmap **app; + ListCell *lc; - for (app = Typ; *app != NULL; app++) + foreach (lc, Typ) { - if (strncmp(NameStr((*app)->am_typ.typname), type, NAMEDATALEN) == 0) + struct typmap *app = lfirst(lc); + if (strncmp(NameStr(app->am_typ.typname), type, NAMEDATALEN) == 0) { - Ap = *app; - return (*app)->am_oid; + Ap = app; + return app->am_oid; } } } @@ -980,14 +970,17 @@ boot_get_type_io_data(Oid typid, if (Typ != NULL) { /* We have the boot-time contents of pg_type, so use it */ - struct typmap **app; - struct typmap *ap; - - app = Typ; - while (*app && (*app)->am_oid != typid) - ++app; - ap = *app; - if (ap == NULL) + struct typmap *ap = NULL; + ListCell *lc; + + foreach (lc, Typ) + { + ap = lfirst(lc); + if (ap->am_oid == typid) + break; + } + + if (!ap || ap->am_oid != typid) elog(ERROR, "type OID %u not found in Typ list", typid); *typlen = ap->am_typ.typlen; -- 2.26.2 --------------76B8D0DC8AE327D516738282 Content-Type: text/x-patch; charset=UTF-8; name="0002-Allow-composite-types-in-bootstrap-20210108.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0002-Allow-composite-types-in-bootstrap-20210108.patch" ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Improve EXPLAIN output for multicolumn B-Tree Index @ 2024-06-21 15:31 Yugo NAGATA <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Yugo NAGATA @ 2024-06-21 15:31 UTC (permalink / raw) To: [email protected]; +Cc: [email protected]; [email protected] On Fri, 21 Jun 2024 07:12:25 +0000 <[email protected]> wrote: > * Is this feature useful? Is there a possibility it will be accepted? I think adding such information to EXPLAIN outputs is useful because it will help users confirm the effect of a multicolumn index on a certain query and decide to whether leave, drop, or recreate the index, and so on. > * Are there any other ideas for determining if multicolumn indexes are > > being used efficiently? Although I considered calculating the efficiency using > > pg_statio_all_indexes.idx_blks_read and pg_stat_all_indexes.idx_tup_read, > > I believe improving the EXPLAIN output is better because it can be output > > per query and it's more user-friendly. It seems for me improving EXPLAIN is a natural way to show information on query optimization like index scans. > * Is "Index Bound Cond" the proper term?I also considered changing > > "Index Cond" to only show quals for the boundary condition and adding > > a new term "Index Filter". "Index Bound Cond" seems not intuitive for me because I could not find description explaining what this means from the documentation. I like "Index Filter" that implies the index has to be scanned. > * Would it be better to add new interfaces to Index AM? Is there any case > > to output the EXPLAIN for each index context? At least, I think it's worth > > considering whether it's good for amcostestimate() to modify the > > IndexPath directly as the PoC patch does. I am not sure it is the best way to modify IndexPath in amcostestimate(), but I don't have better ideas for now. Regards, Yugo Nagata > > > > > Regards, > > -- > > Masahiro Ikeda > > NTT DATA CORPORATION > > -- Yugo NAGATA <[email protected]> ^ permalink raw reply [nested|flat] 3+ messages in thread
* RE: Improve EXPLAIN output for multicolumn B-Tree Index @ 2024-06-24 02:52 [email protected] parent: Yugo NAGATA <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: [email protected] @ 2024-06-24 02:52 UTC (permalink / raw) To: [email protected]; +Cc: [email protected]; [email protected] > > * Is this feature useful? Is there a possibility it will be accepted? > > I think adding such information to EXPLAIN outputs is useful because it will help users > confirm the effect of a multicolumn index on a certain query and decide to whether > leave, drop, or recreate the index, and so on. Thank you for your comments and for empathizing with the utility of the approach. > > * Are there any other ideas for determining if multicolumn indexes are > > > > being used efficiently? Although I considered calculating the > > efficiency using > > > > pg_statio_all_indexes.idx_blks_read and > > pg_stat_all_indexes.idx_tup_read, > > > > I believe improving the EXPLAIN output is better because it can be > > output > > > > per query and it's more user-friendly. > > It seems for me improving EXPLAIN is a natural way to show information on query > optimization like index scans. OK, I'll proceed with the way. > > * Is "Index Bound Cond" the proper term?I also considered changing > > > > "Index Cond" to only show quals for the boundary condition and adding > > > > a new term "Index Filter". > > "Index Bound Cond" seems not intuitive for me because I could not find description > explaining what this means from the documentation. I like "Index Filter" that implies the > index has to be scanned. OK, I think you are right. Even at this point, there are things like ‘Filter’ and ‘Rows Removed by Filter’, so it seems natural to align with them. I described a new output example in the previous email, how about that? > > * Would it be better to add new interfaces to Index AM? Is there any > > case > > > > to output the EXPLAIN for each index context? At least, I think it's > > worth > > > > considering whether it's good for amcostestimate() to modify the > > > > IndexPath directly as the PoC patch does. > > I am not sure it is the best way to modify IndexPath in amcostestimate(), but I don't > have better ideas for now. OK, I’ll consider what the best way to change is. In addition, if we add "Rows Removed by Index Filter", we might need to consider a method to receive the number of filtered tuples at execution time from Index AM. Regards, -- Masahiro Ikeda NTT DATA CORPORATION ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-06-24 02:52 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-11-20 02:48 [PATCH 1/3] bootstrap: convert Typ to a List* Justin Pryzby <[email protected]> 2024-06-21 15:31 Re: Improve EXPLAIN output for multicolumn B-Tree Index Yugo NAGATA <[email protected]> 2024-06-24 02:52 ` RE: Improve EXPLAIN output for multicolumn B-Tree Index [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