Re: remaining sql/json patches
amit <amitlangote09@gmail.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
SQL/JSON: Various improvements to SQL/JSON query function docs
- ce416fadb4b6 17.0 landed
- 42de72fa7b80 18.0 landed
-
SQL/JSON: Fix some obsolete comments.
- 290a6d800d90 17.0 landed
- 7768b6569de9 16.4 landed
- 3a8a1f3254b2 18.0 landed
-
SQL/JSON: Fix issues with DEFAULT .. ON ERROR / EMPTY
- c0fc0751862d 17.0 landed
-
JSON_TABLE: Add support for NESTED paths and columns
- bb766cde63b4 17.0 landed
-
Fix JsonExpr deparsing to emit QUOTES and WRAPPER correctly
- f6a2529920cf 17.0 landed
-
Fix typo introduced in 6185c9737
- 2f6e78b0619a 17.0 landed
-
Add basic JSON_TABLE() functionality
- de3600452b61 17.0 landed
-
Avoid splitting errmsg string to span multiple lines
- 085e759e9da7 17.0 landed
-
Add SQL/JSON query functions
- 6185c9737cf4 17.0 landed
-
Implement various jsonpath methods
- 66ea94e8e606 17.0 cited
-
Add soft error handling to some expression nodes
- aaaf9449ec6b 17.0 landed
- 7fbc75b26ed8 17.0 landed
-
Adjust populate_record_field() to handle errors softly
- 1edb3b491bee 17.0 landed
-
Refactor code used by jsonpath executor to fetch variables
- faa2b953ba3b 17.0 landed
-
Test EXPLAIN (FORMAT JSON) ... XMLTABLE
- 752533d40fd5 17.0 landed
-
Simplify productions for FORMAT JSON [ ENCODING name ]
- d3fe6e90bab5 17.0 landed
-
Add trailing commas to enum definitions
- 611806cd726f 17.0 cited
-
doc: add missing <returnvalue> and whitespace
- e055b6be7ebb 17.0 landed
-
Add more SQL/JSON constructor functions
- 03734a7fed7d 17.0 landed
-
Rename a nonterminal used in SQL/JSON grammar
- 254ac5a7c31f 17.0 landed
-
Some refactoring to export json(b) conversion functions
- b22391a2ff7b 17.0 landed
-
Don't include CaseTestExpr in JsonValueExpr.formatted_expr
- 66a9003e2e3e 16.0 landed
- b6e1157e7d33 17.0 landed
-
Code review for commit b6e1157e7d
- 7c7412cae3ea 17.0 landed
-
Pass constructName to transformJsonValueExpr()
- 7825a1b01e40 16.0 landed
- 785480c9533d 17.0 landed
-
Unify JSON categorize type API and export for external use
- 3c152a27b063 17.0 landed
-
Make some indentation in gram.y consistent
- 5edf438eeb00 17.0 landed
- 01f1f789df56 16.0 landed
-
Allow most keywords to be used as column labels without requiring AS.
- 06a7c3154f5b 14.0 cited
-
Reduce size of backend scanner's tables.
- 7f380c59f800 13.0 cited
-
Use perfect hashing, instead of binary search, for keyword lookup.
- c64d0cd5ce24 12.0 cited
On Thu, Nov 16, 2023 at 2:11 AM Andres Freund <andres@anarazel.de> wrote: > On 2023-11-15 22:00:41 +0900, Amit Langote wrote: > > > This causes a nontrivial increase in the size of the parser (~5% in an > > > optimized build here), I wonder if we can do better. > > > > Hmm, sorry if I sound ignorant but what do you mean by the parser here? > > gram.o, in an optimized build. > > > I can see that the byte-size of gram.o increases by 1.66% after the > > above additions (1.72% with previous versions). > > I'm not sure anymore how I measured it, but if you just looked at the total > file size, that might not show the full gain, because of debug symbols > etc. You can use the size command to look at just the code and data size. $ size /tmp/gram.* text data bss dec hex filename 661808 0 0 661808 a1930 /tmp/gram.o.unpatched 672800 0 0 672800 a4420 /tmp/gram.o.patched That's still a 1.66% increase in the code size: (672800 - 661808) / 661808 % = 1.66 As for gram.c, the increase is a bit larger: $ ll /tmp/gram.* -rw-rw-r--. 1 amit amit 2605925 Nov 16 16:18 /tmp/gram.c.unpatched -rw-rw-r--. 1 amit amit 2709422 Nov 16 16:22 /tmp/gram.c.patched (2709422 - 2605925) / 2605925 % = 3.97 > > I've also checked > > using log_parser_stats that there isn't much slowdown in the > > raw-parsing speed. > > What does "isn't much slowdown" mean in numbers? Sure, the benchmark I used measured the elapsed time (using log_parser_stats) of parsing a simple select statement (*) averaged over 10000 repetitions of the same query performed with `psql -c`: Unpatched: 0.000061 seconds Patched: 0.000061 seconds Here's a look at the perf: Unpatched: 0.59% [.] AllocSetAlloc 0.51% [.] hash_search_with_hash_value 0.47% [.] base_yyparse Patched: 0.63% [.] AllocSetAlloc 0.52% [.] hash_search_with_hash_value 0.44% [.] base_yyparse (*) select 1, 2, 3 from foo where a = 1 Is there a more relevant benchmark I could use? -- Thanks, Amit Langote EDB: http://www.enterprisedb.com