{"push_id":3149553081,"size":7,"distinct_size":1,"ref":"refs/heads/commitfest/21/1802","head":"de46c279491ce0457fcdad7c683f8fbcdea6d3c9","before":"824f2f337a2f44752c9dabff62887c425850464a","commits":[{"sha":"f94cec64476f2752e91b10d7928a2fcd105e9fc3","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Include partitioned indexes to system view pg_indexes\n\npg_tables already includes partitioned tables, so for consistency\npg_indexes should show partitioned indexes.\n\nAuthor: Suraj Kharage\nReviewed-by: Amit Langote, Michael Paquier\nDiscussion: https://postgr.es/m/CAF1DzPVrYo4XNTEnc=PqVp6aLJc7LFYpYR4rX=_5pV=wJ2KdZg@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/f94cec64476f2752e91b10d7928a2fcd105e9fc3"},{"sha":"d364e88155ac895710c28efb0330b0c9594300eb","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Fix ancient thinko in mergejoin cost estimation.\n\n\"rescanratio\" was computed as 1 + rescanned-tuples / total-inner-tuples,\nwhich is sensible if it's to be multiplied by total-inner-tuples or a cost\nvalue corresponding to scanning all the inner tuples.  But in reality it\nwas (mostly) multiplied by inner_rows or a related cost, numbers that take\ninto account the possibility of stopping short of scanning the whole inner\nrelation thanks to a limited key range in the outer relation.  This'd\nstill make sense if we could expect that stopping short would result in a\nproportional decrease in the number of tuples that have to be rescanned.\nIt does not, however.  The argument that establishes the validity of our\nestimate for that number is independent of whether we scan all of the inner\nrelation or stop short, and experimentation also shows that stopping short\ndoesn't reduce the number of rescanned tuples.  So the correct calculation\nis 1 + rescanned-tuples / inner_rows, and we should be sure to multiply\nthat by inner_rows or a corresponding cost value.\n\nMost of the time this doesn't make much difference, but if we have\nboth a high rescan rate (due to lots of duplicate values) and an outer\nkey range much smaller than the inner key range, then the error can\nbe significant, leading to a large underestimate of the cost associated\nwith rescanning.\n\nPer report from Vijaykumar Jain.  This thinko appears to go all the way\nback to the introduction of the rescan estimation logic in commit\n70fba7043, so back-patch to all supported branches.\n\nDiscussion: https://postgr.es/m/CAE7uO5hMb_TZYJcZmLAgO6iD68AkEK6qCe7i=vZUkCpoKns+EQ@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/d364e88155ac895710c28efb0330b0c9594300eb"},{"sha":"b2d9e17768864030fb0829b55303b8b72bfd809f","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Update sepgsql regression test results for commit ca4103025.\n\nPer buildfarm.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/b2d9e17768864030fb0829b55303b8b72bfd809f"},{"sha":"6b0faf723647a851eaaddfed11e14861f8d0f588","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Make collation-aware system catalog columns use \"C\" collation.\n\nUp to now we allowed text columns in system catalogs to use collation\n\"default\", but that isn't really safe because it might mean something\ndifferent in template0 than it means in a database cloned from template0.\nIn particular, this could mean that cloned pg_statistic entries for such\ncolumns weren't entirely valid, possibly leading to bogus planner\nestimates, though (probably) not any outright failures.\n\nIn the wake of commit 5e0928005, a better solution is available: if we\nlabel such columns with \"C\" collation, then their pg_statistic entries\nwill also use that collation and hence will be valid independently of\nthe database collation.\n\nThis also provides a cleaner solution for indexes on such columns than\nthe hack added by commit 0b28ea79c: the indexes will naturally inherit\n\"C\" collation and don't have to be forced to use text_pattern_ops.\n\nAlso, with the planned improvement of type \"name\" to be collation-aware,\nthis policy will apply cleanly to both text and name columns.\n\nBecause of the pg_statistic angle, we should also apply this policy\nto the tables in information_schema.  This patch does that by adjusting\ninformation_schema's textual domain types to specify \"C\" collation.\nThat has the user-visible effect that order-sensitive comparisons to\ntextual information_schema view columns will now use \"C\" collation\nby default.  The SQL standard says that the collation of those view\ncolumns is implementation-defined, so I think this is legal per spec.\nAt some point this might allow for translation of such comparisons\ninto indexable conditions on the underlying \"name\" columns, although\nadditional work will be needed before that can happen.\n\nDiscussion: https://postgr.es/m/19346.1544895309@sss.pgh.pa.us","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/6b0faf723647a851eaaddfed11e14861f8d0f588"},{"sha":"3cab54878dbf212c08699bb974b069bdc43bff61","author":{"name":"Tatsuo Ishii","email":"d65e86e9f63e8ebd237ae089e7c4417e05d5f9dd@postgresql.org"},"message":"Doc: fix typo in \"Generic File Access Functions\" section.\n\nIssue reported by me and fix by Tom Lane.\nDiscussion: https://postgr.es/m/20181219.080458.1434575730369741406.t-ishii%40sraoss.co.jp","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/3cab54878dbf212c08699bb974b069bdc43bff61"},{"sha":"60f3cc9553c7ea7a1cc61bcd1efe51537f31e531","author":{"name":"Peter Geoghegan","email":"96dd8d96902e9c5af3b96b1eaa9c80cbc615d290@bowt.ie"},"message":"Correct obsolete nbtree recovery comments.\n\nCommit 40dae7ec537, which made the handling of interrupted nbtree page\nsplits more robust, removed an nbtree-specific end-of-recovery cleanup\nstep.  This meant that it was no longer possible to complete an\ninterrupted page split during recovery.  However, a reference to\nrecovery as a reason for using a NULL stack while inserting into a\nparent page was missed.  Remove the reference.\n\nRemove a similar obsolete reference to recovery that was introduced much\nmore recently, as part of the btree fastpath optimization enhancement\nthat made it into Postgres 11 (commit 2b272734, and follow-up commits).\n\nBackpatch: 11-, where the fastpath optimization was introduced.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/60f3cc9553c7ea7a1cc61bcd1efe51537f31e531"},{"sha":"de46c279491ce0457fcdad7c683f8fbcdea6d3c9","author":{"name":"Commitfest Bot","email":"b9e638e07cc2e2abf56c9c0cad7954f2e3bc1641@cputube.org"},"message":"[CF 21/1802] Retail IndexTuple Deletion\n\nThis commit was automatically generated by cfbot at commitfest.cputube.org.\nIt is based on patches submitted to the PostgreSQL mailing lists and\nregistered in the PostgreSQL Commitfest application.\n\nThis branch will be overwritten each time a new patch version is posted to\nthe email thread, and also periodically to check for bitrot caused by changes\non the master branch.\n\nCommitfest entry: https://commitfest.postgresql.org/21/1802\nPatch(es): https://www.postgresql.org/message-id/c5a8f52b-6b61-e6f6-aa22-0f4bd0909b63@postgrespro.ru\nAuthor(s): Andrey Lepikhov","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/de46c279491ce0457fcdad7c683f8fbcdea6d3c9"}]}
{"actor":{"display_login":"postgresql-cfbot"}}