[COMMITTERS] pgsql: Fix assorted integer-overflow hazards in varbit.c.

Fix assorted integer-overflow hazards in varbit.c. bitshiftright() and bitshiftleft() would recursively call each other infinitely if the user passed INT_MIN for the shift amount, due to integer overflow in negating the shift amount. To fix, clamp to -VARBITMAXLEN. That doesn't change the results

[COMMITTERS] pgsql: Fix assorted integer-overflow hazards in varbit.c.

Fix assorted integer-overflow hazards in varbit.c. bitshiftright() and bitshiftleft() would recursively call each other infinitely if the user passed INT_MIN for the shift amount, due to integer overflow in negating the shift amount. To fix, clamp to -VARBITMAXLEN. That doesn't change the results

[COMMITTERS] pgsql: Fix assorted integer-overflow hazards in varbit.c.

Fix assorted integer-overflow hazards in varbit.c. bitshiftright() and bitshiftleft() would recursively call each other infinitely if the user passed INT_MIN for the shift amount, due to integer overflow in negating the shift amount. To fix, clamp to -VARBITMAXLEN. That doesn't change the results

[COMMITTERS] pgsql: Fix assorted integer-overflow hazards in varbit.c.

Fix assorted integer-overflow hazards in varbit.c. bitshiftright() and bitshiftleft() would recursively call each other infinitely if the user passed INT_MIN for the shift amount, due to integer overflow in negating the shift amount. To fix, clamp to -VARBITMAXLEN. That doesn't change the results

[COMMITTERS] pgsql: Fix assorted integer-overflow hazards in varbit.c.

Fix assorted integer-overflow hazards in varbit.c. bitshiftright() and bitshiftleft() would recursively call each other infinitely if the user passed INT_MIN for the shift amount, due to integer overflow in negating the shift amount. To fix, clamp to -VARBITMAXLEN. That doesn't change the results

[COMMITTERS] pgsql: Fix assorted integer-overflow hazards in varbit.c.

Fix assorted integer-overflow hazards in varbit.c. bitshiftright() and bitshiftleft() would recursively call each other infinitely if the user passed INT_MIN for the shift amount, due to integer overflow in negating the shift amount. To fix, clamp to -VARBITMAXLEN. That doesn't change the results

[COMMITTERS] pgsql: Fix assorted integer-overflow hazards in varbit.c.

Fix assorted integer-overflow hazards in varbit.c. bitshiftright() and bitshiftleft() would recursively call each other infinitely if the user passed INT_MIN for the shift amount, due to integer overflow in negating the shift amount. To fix, clamp to -VARBITMAXLEN. That doesn't change the results

[COMMITTERS] pgsql: Remove spurious word.

Remove spurious word. Tatsuo Ishii Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/db4b54f1550aa830890ce190e5d196de8d17db33 Author: Robert Haas Modified Files -- doc/src/sgml/parallel.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --

[COMMITTERS] pgsql: Add a macro templatized hashtable.

Add a macro templatized hashtable. dynahash.c hash tables aren't quite fast enough for some use-cases. There are several reasons for lacking performance: - the use of chaining for collision handling makes them cache inefficient, that's especially an issue when the tables get bigger. - as the ele

[COMMITTERS] pgsql: Add likely/unlikely() branch hint macros.

Add likely/unlikely() branch hint macros. These are useful for very hot code paths. Because it's easy to guess wrongly about likelihood, and because such likelihoods change over time, they should be used sparingly. Past tests have shown it'd be a good idea to use them in some places, e.g. in erro

[COMMITTERS] pgsql: Use more efficient hashtable for tidbitmap.c to speed up bitmap

Use more efficient hashtable for tidbitmap.c to speed up bitmap scans. Use the new simplehash.h to speed up tidbitmap.c uses. For bitmap scan heavy queries speedups of over 100% have been measured. Both lossy and exact scans benefit, but the wins are bigger for mostly exact scans. The conversion

[COMMITTERS] pgsql: Use more efficient hashtable for execGrouping.c to speed up hash

Use more efficient hashtable for execGrouping.c to speed up hash aggregation. The more efficient hashtable speeds up hash-aggregations with more than a few hundred groups significantly. Improvements of over 120% have been measured. Due to the the different hash table queries that not fully determ