pgsql: Make new regression indpendent of max_parallel_workers_per_gath

Make new regression indpendent of max_parallel_workers_per_gather. The tests in e2f1eb0ee30d1 ("Implement partition-wise grouping/aggregation.") weren't independent of the server's max_parallel_workers_per_gather setting. I (Andres) find it useful to locally run with that disabled, and the

pgsql: JIT tuple deforming in LLVM JIT provider.

JIT tuple deforming in LLVM JIT provider. Performing JIT compilation for deforming gains performance benefits over unJITed deforming from compile-time knowledge of the tuple descriptor. Fixed column widths, NOT NULLness, etc can be taken advantage of. Right now the JITed deforming is only used

pgsql: Fix thinko in comment

Fix thinko in comment The listed numbers disagreed with the ones being used in the symbols; but instead of just fixing the numbers in the comment, use the symbolic name instead, which seems clearer. This has been wrong all along, so apply back to 9.5 where BRIN was introduced. Reported-by:

pgsql: Fix thinko in comment

Fix thinko in comment The listed numbers disagreed with the ones being used in the symbols; but instead of just fixing the numbers in the comment, use the symbolic name instead, which seems clearer. This has been wrong all along, so apply back to 9.5 where BRIN was introduced. Reported-by:

pgsql: Fix test impredictability

Fix test impredictability Test 'triggers' fails when another one creates triggers concurrently at some precise time, because of a missing WHERE clause. Per buildfarm members snapper, desmoxytes. Branch -- master Details ---

pgsql: Fix thinko in comment

Fix thinko in comment The listed numbers disagreed with the ones being used in the symbols; but instead of just fixing the numbers in the comment, use the symbolic name instead, which seems clearer. This has been wrong all along, so apply back to 9.5 where BRIN was introduced. Reported-by:

pgsql: Fix thinko in comment

Fix thinko in comment The listed numbers disagreed with the ones being used in the symbols; but instead of just fixing the numbers in the comment, use the symbolic name instead, which seems clearer. This has been wrong all along, so apply back to 9.5 where BRIN was introduced. Reported-by:

Re: pgsql: Allow FOR EACH ROW triggers on partitioned tables

Alvaro Herrera writes: > Andres Freund wrote: >> The inherit.sql here looks like it's racing against the concurrentlys >> scheduled triggers.sql according to my new desmoxytes animal: >>

Re: pgsql: Allow FOR EACH ROW triggers on partitioned tables

Andres Freund wrote: > On 2018-03-23 13:48:53 +, Alvaro Herrera wrote: > > Allow FOR EACH ROW triggers on partitioned tables > The inherit.sql here looks like it's racing against the concurrentlys > scheduled triggers.sql according to my new desmoxytes animal: >

pgsql: Handle INSERT .. ON CONFLICT with partitioned tables

Handle INSERT .. ON CONFLICT with partitioned tables Commit eb7ed3f30634 enabled unique constraints on partitioned tables, but one thing that was not working properly is INSERT/ON CONFLICT. This commit introduces a new node keeps state related to the ON CONFLICT clause per partition, and fills it

pgsql: Fix typo

Fix typo Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1b89c2188bd38eac68251f16051859996128f2d0 Modified Files -- src/backend/optimizer/plan/setrefs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Fix typo

Fix typo Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/29c5e341733f3fcc4b790857d663f73a41e6e194 Modified Files -- src/backend/optimizer/plan/setrefs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Remove two tests inadvertently added in 2b27273435

Remove two tests inadvertently added in 2b27273435 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1d494b622fa9dfdbd7213f357cd38def0125a322 Modified Files -- src/test/regress/expected/indexing.out | 16 src/test/regress/sql/indexing.sql

pgsql: Optimize btree insertions for common case of increasing values

Optimize btree insertions for common case of increasing values Remember the last page of an index insert if it's the rightmost leaf page. If the next entry belongs on and can fit in the remembered page, insert the new entry there as long as we can get a lock on the page. Otherwise, fall back on