Re: Generating code for query jumbling through gen_node_support.pl
| От | Michael Paquier |
|---|---|
| Тема | Re: Generating code for query jumbling through gen_node_support.pl |
| Дата | |
| Msg-id | Y+V4iQgI0DKi8pnE@paquier.xyz обсуждение исходный текст |
| Ответ на | Re: Generating code for query jumbling through gen_node_support.pl (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: Generating code for query jumbling through gen_node_support.pl
|
| Список | pgsql-hackers |
On Wed, Feb 08, 2023 at 03:47:51PM +0900, Michael Paquier wrote: > This one was intentional to let extensions play with jumbling of such > nodes, but perhaps you are right that it makes little sense at this > stage. If there is an ask for it later, though.. Using > shared_preload_libraries = pg_stat_statements and compute_query_id = > regress shows that numbers go up to 60% for funcs.c and 30% for > switch.c. Removing nodes like as of the attached brings these numbers > respectively up to 94.5% and 93.5% for a check. With a check-world, I > measure respectively 96.7% and 96.1% because there is more coverage > for extensions, ALTER SYSTEM and database commands, roughly. Tom, did you get a chance to look at what is proposed here and expand the use of query_jumble_ignore in the definitions of the nodes rather than have an enforced per-file policy in gen_node_support.pl? The attached improves the situation by as much as we can, still the numbers reported by coverage.postgresql.org won't go that up until we enforce query jumbling testing on the regression database (something we should have done since this code moved to core, I guess). -- Michael
Вложения
В списке pgsql-hackers по дате отправления: