postgres

Commit Graph

Author	SHA1	Message	Date
Tom Lane	0245f8db36	Pre-beta mechanical code beautification. Run pgindent, pgperltidy, and reformat-dat-files. This set of diffs is a bit larger than typical. We've updated to pg_bsd_indent 2.1.2, which properly indents variable declarations that have multi-line initialization expressions (the continuation lines are now indented one tab stop). We've also updated to perltidy version 20230309 and changed some of its settings, which reduces its desire to add whitespace to lines to make assignments etc. line up. Going forward, that should make for fewer random-seeming changes to existing code. Discussion: https://postgr.es/m/20230428092545.qfb3y5wcu4cm75ur@alvherre.pgsql	3 years ago
Bruce Momjian	c8e1ba736b	Update copyright for 2023 Backpatch-through: 11	3 years ago
Tom Lane	23e7b38bfe	Pre-beta mechanical code beautification. Run pgindent, pgperltidy, and reformat-dat-files. I manually fixed a couple of comments that pgindent uglified.	4 years ago
Bruce Momjian	27b77ecf9f	Update copyright for 2022 Backpatch-through: 10	4 years ago
John Naylor	ba958299ea	Speed up generation of Unicode hash functions. Sets of Unicode keys are picky about the primes used when generating a perfect hash function for them. Callers can spend many seconds iterating through all the possible combinations of candidate multipliers and seeds to find one that works. Unicode updates typically happen only once a year, but it still makes development and testing of Unicode scripts unnecessarily slow. To fix, iterate over the primes in the innermost loop. This does not change any existing functions checked into the tree.	4 years ago
Bruce Momjian	ca3b37487b	Update copyright for 2021 Backpatch-through: 9.5	5 years ago
Michael Paquier	19ae53c92d	Review format of code generated by PerfectHash.pm `80f8eb7` has added to the normalization quick check headers some code generated by PerfectHash.pm that is incompatible with the settings of gitattributes for this repository, as whitespaces followed a set of tabs for the first element of a line in the table. Instead of adding a new exception to gitattributes, rework the format generated so as a right padding with spaces is used instead of a left padding. This keeps the table generated in a readable shape with its set of columns, making unnecessary an update of gitattributes. Reported-by: Peter Eisentraut Author: John Naylor Discussion: https://postgr.es/m/d601b3b5-a3c7-5457-2f84-3d6513d690fc@2ndquadrant.com	5 years ago
Michael Paquier	2a73164581	Improve set of candidate multipliers for perfect hash function generation The previous set of multipliers was not adapted for large sets of short keys, and this new set of multipliers allows to generate perfect hash functions for larger sets without having an impact for existing callers of those functions, as experimentation has showed. A future commit will make use of that to improve the performance of unicode normalization. All multipliers compile to shift-and-add instructions on most platforms. This has been tested as far back as gcc 4.1 and clang 3.8. Author: John Naylor Reviewed-by: Mark Dilger, Michael Paquier Discussion: https://postgr.es/m/CACPNZCt4fbJ0_bGrN5QPt34N4whv=mszM0LMVQdoa2rC9UMRXA@mail.gmail.com	5 years ago
Bruce Momjian	7559d8ebfa	Update copyrights for 2020 Backpatch-through: update all files in master, backpatch legal files through 9.4	6 years ago
Tom Lane	9e58705a7f	Make our perfect hash functions be valid C++. While C is happy to cast "const void " to "const unsigned char " silently, C++ insists on an explicit cast. Since we put these functions into header files, cpluspluscheck whines about that. Add the cast to pacify it. Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru	7 years ago
Tom Lane	c64d0cd5ce	Use perfect hashing, instead of binary search, for keyword lookup. We've been speculating for a long time that hash-based keyword lookup ought to be faster than binary search, but up to now we hadn't found a suitable tool for generating the hash function. Joerg Sonnenberger provided the inspiration, and sample code, to show us that rolling our own generator wasn't a ridiculous idea. Hence, do that. The method used here requires a lookup table of approximately 4 bytes per keyword, but that's less than what we saved in the predecessor commit `afb0d0712`, so it's not a big problem. The time savings is indeed significant: preliminary testing suggests that the total time for raw parsing (flex + bison phases) drops by ~20%. Patch by me, but it owes its existence to Joerg Sonnenberger; thanks also to John Naylor for review. Discussion: https://postgr.es/m/20190103163340.GA15803@britannica.bec.de	7 years ago

11 Commits (da98d005cdbcd45af563d0c4ac86d0e9772cd15f)