Re: pgsql: Fix incorrect handling of join clauses pushed into parameterized

On Thu, Apr 19, 2018 at 3:49 PM, Tom Lane wrote: > Fix incorrect handling of join clauses pushed into parameterized paths. > > In some cases a clause attached to an outer join can be pushed down into > the outer join's RHS even though the clause is not degenerate --- this > can happen if we choose

pgsql: Fix broken extract_actual_join_clauses call in 9.6 postgres_fdw.

Fix broken extract_actual_join_clauses call in 9.6 postgres_fdw. In commits e5d83995e et al, I changed the signature of extract_actual_join_clauses, thinking that it was not called from anywhere but createplan.c. I missed that postgres_fdw uses it in the 9.6 branch only. This opens up the questi

pgsql: Improve consistency of comments in system catalog headers.

Improve consistency of comments in system catalog headers. Use the term "system catalog" rather than "system relation" in assorted places where it's clearly referring to a table rather than, say, an index. Use more natural word order in the header boilerplate, improve some of the one-liner catalo

pgsql: Fix incorrect handling of join clauses pushed into parameterized

Fix incorrect handling of join clauses pushed into parameterized paths. In some cases a clause attached to an outer join can be pushed down into the outer join's RHS even though the clause is not degenerate --- this can happen if we choose to make a parameterized path for the RHS. If the clause e

pgsql: Fix incorrect handling of join clauses pushed into parameterized

Fix incorrect handling of join clauses pushed into parameterized paths. In some cases a clause attached to an outer join can be pushed down into the outer join's RHS even though the clause is not degenerate --- this can happen if we choose to make a parameterized path for the RHS. If the clause e

pgsql: Fix incorrect handling of join clauses pushed into parameterized

Fix incorrect handling of join clauses pushed into parameterized paths. In some cases a clause attached to an outer join can be pushed down into the outer join's RHS even though the clause is not degenerate --- this can happen if we choose to make a parameterized path for the RHS. If the clause e

pgsql: Fix incorrect handling of join clauses pushed into parameterized

Fix incorrect handling of join clauses pushed into parameterized paths. In some cases a clause attached to an outer join can be pushed down into the outer join's RHS even though the clause is not degenerate --- this can happen if we choose to make a parameterized path for the RHS. If the clause e

pgsql: Fix incorrect handling of join clauses pushed into parameterized

Fix incorrect handling of join clauses pushed into parameterized paths. In some cases a clause attached to an outer join can be pushed down into the outer join's RHS even though the clause is not degenerate --- this can happen if we choose to make a parameterized path for the RHS. If the clause e

pgsql: Fix incorrect handling of join clauses pushed into parameterized

Fix incorrect handling of join clauses pushed into parameterized paths. In some cases a clause attached to an outer join can be pushed down into the outer join's RHS even though the clause is not degenerate --- this can happen if we choose to make a parameterized path for the RHS. If the clause e

pgsql: Remove quick path in ExecInitPartitionInfo for equal tupdescs

Remove quick path in ExecInitPartitionInfo for equal tupdescs I added this "optimization" on top of Amit Langote's 158b7bc6d779, but the quick path is never taken because the partition uses a different pg_type oid than its parent table (causing equalTupleDescs to return false). Changing that requ

pgsql: Plural of modulus is moduli

Plural of modulus is moduli Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2d625176c013ed185250aab3f8a1d175d81d4f3b Modified Files -- src/backend/partitioning/partbounds.c | 6 +++--- src/backend/utils/cache/partcache.c | 2 +- 2 files changed, 4 insert

pgsql: Rework code to determine partition pruning procedure

Rework code to determine partition pruning procedure Amit Langote reported that partition prune was unable to work with arrays, enums, etc, which led him to research the appropriate way to match query clauses to partition keys: instead of searching for an exact match of the expression's type, it i

pgsql: Enlarge find_other_exec's meager fgets buffer

Enlarge find_other_exec's meager fgets buffer The buffer was 100 bytes long, which is barely sufficient when the version string gets longer (such as by configure --with-extra-version). Set it to MAXPGPATH. Author: Nikhil Sontakke Discussion: https://postgr.es/m/camgcdxflfpyu_jru++l6arpcoyxr0w+2o

pgsql: Enlarge find_other_exec's meager fgets buffer

Enlarge find_other_exec's meager fgets buffer The buffer was 100 bytes long, which is barely sufficient when the version string gets longer (such as by configure --with-extra-version). Set it to MAXPGPATH. Author: Nikhil Sontakke Discussion: https://postgr.es/m/camgcdxflfpyu_jru++l6arpcoyxr0w+2o

pgsql: Enlarge find_other_exec's meager fgets buffer

Enlarge find_other_exec's meager fgets buffer The buffer was 100 bytes long, which is barely sufficient when the version string gets longer (such as by configure --with-extra-version). Set it to MAXPGPATH. Author: Nikhil Sontakke Discussion: https://postgr.es/m/camgcdxflfpyu_jru++l6arpcoyxr0w+2o

pgsql: Enlarge find_other_exec's meager fgets buffer

Enlarge find_other_exec's meager fgets buffer The buffer was 100 bytes long, which is barely sufficient when the version string gets longer (such as by configure --with-extra-version). Set it to MAXPGPATH. Author: Nikhil Sontakke Discussion: https://postgr.es/m/camgcdxflfpyu_jru++l6arpcoyxr0w+2o

pgsql: Enlarge find_other_exec's meager fgets buffer

Enlarge find_other_exec's meager fgets buffer The buffer was 100 bytes long, which is barely sufficient when the version string gets longer (such as by configure --with-extra-version). Set it to MAXPGPATH. Author: Nikhil Sontakke Discussion: https://postgr.es/m/camgcdxflfpyu_jru++l6arpcoyxr0w+2o

pgsql: Enlarge find_other_exec's meager fgets buffer

Enlarge find_other_exec's meager fgets buffer The buffer was 100 bytes long, which is barely sufficient when the version string gets longer (such as by configure --with-extra-version). Set it to MAXPGPATH. Author: Nikhil Sontakke Discussion: https://postgr.es/m/camgcdxflfpyu_jru++l6arpcoyxr0w+2o

Re: pgsql: Skip full index scan during cleanup of B-tree indexes when possi

Thank you, both patches are pushed. Alexander Korotkov wrote: On Wed, Apr 18, 2018 at 9:21 PM, Peter Geoghegan > wrote: On Wed, Apr 18, 2018 at 11:12 AM, Fujii Masao mailto:masao.fu...@gmail.com>> wrote: > On Thu, Apr 5, 2018 at 1:29 AM, Teodor Sigaev mailto:teo...@

pgsql: Fix datatype for number of heap tuples during last cleanup

Fix datatype for number of heap tuples during last cleanup It appears that new fields introduced in 857f9c36 have inconsistent datatypes: BTMetaPageData.btm_last_cleanup_num_heap_tuples is of float4 type, while xl_btree_metadata.last_cleanup_num_heap_tuples is of double type. IndexVacuumInfo.num_h

pgsql: Adjust _bt_insertonpg() comments

Adjust _bt_insertonpg() comments Remove an obsolete reference to the 'afteritem' argument, which was removed by commit bc292937. Add a comment that clarifies how _bt_insertonpg() indirectly handles the insertion of high key items. Author: Peter Geoghegan Branch -- master Details --- ht

Re: pgsql: Skip full index scan during cleanup of B-tree indexes when possi

On Thu, Apr 19, 2018 at 9:19 AM, Teodor Sigaev wrote: > Another thing that I noticed is that the metapage stores >> btm_last_cleanup_num_heap_tuples as a float4, even though >> xl_btree_metadata stores it as a double. I suggest that both places >> store it as float8, to be consist