{"push_id":2934604738,"size":4,"distinct_size":1,"ref":"refs/heads/commitfest/20/1490","head":"7bda0a0dee9a2064947d97c85fadbb4638d51639","before":"d543483212b4f6971356d971cc8c46f094d43870","commits":[{"sha":"9ddef36278a9f676c07d0b4d9f33fa22e48ce3b5","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Centralize executor's opening/closing of Relations for rangetable entries.\n\nCreate an array estate->es_relations[] paralleling the es_range_table,\nand store references to Relations (relcache entries) there, so that any\ngiven RT entry is opened and closed just once per executor run.  Scan\nnodes typically still call ExecOpenScanRelation, but ExecCloseScanRelation\nis no more; relation closing is now done centrally in ExecEndPlan.\n\nThis is slightly more complex than one would expect because of the\ninteractions with relcache references held in ResultRelInfo nodes.\nThe general convention is now that ResultRelInfo->ri_RelationDesc does\nnot represent a separate relcache reference and so does not need to be\nexplicitly closed; but there is an exception for ResultRelInfos in the\nes_trig_target_relations list, which are manufactured by\nExecGetTriggerResultRel and have to be cleaned up by\nExecCleanUpTriggerState.  (That much was true all along, but these\nResultRelInfos are now more different from others than they used to be.)\n\nTo allow the partition pruning logic to make use of es_relations[] rather\nthan having its own relcache references, adjust PartitionedRelPruneInfo\nto store an RT index rather than a relation OID.\n\nAmit Langote, reviewed by David Rowley and Jesper Pedersen,\nsome mods by me\n\nDiscussion: https://postgr.es/m/468c85d9-540e-66a2-1dde-fec2b741e688@lab.ntt.co.jp","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/9ddef36278a9f676c07d0b4d9f33fa22e48ce3b5"},{"sha":"d73f4c74dd34b19c19839f7ae09fb96442728509","author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"In the executor, use an array of pointers to access the rangetable.\n\nInstead of doing a lot of list_nth() accesses to es_range_table,\ncreate a flattened pointer array during executor startup and index\ninto that to get at individual RangeTblEntrys.\n\nThis eliminates one source of O(N^2) behavior with lots of partitions.\n(I'm not exactly convinced that it's the most important source, but\nit's an easy one to fix.)\n\nAmit Langote and David Rowley\n\nDiscussion: https://postgr.es/m/468c85d9-540e-66a2-1dde-fec2b741e688@lab.ntt.co.jp","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/d73f4c74dd34b19c19839f7ae09fb96442728509"},{"sha":"9cd92d1a33699f86aa53d44ab04cc3eb50c18d11","author":{"name":"Michael Paquier","email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@paquier.xyz"},"message":"Add pg_ls_tmpdir function\n\nThis lists the contents of a temporary directory associated to a given\ntablespace, useful to get information about on-disk consumption caused\nby temporary files used by a session query.  By default, pg_default is\nscanned, and a tablespace can be specified as argument.\n\nThis function is intended to be used by monitoring tools, and, unlike\npg_ls_dir(), access to them can be granted to non-superusers so that\nthose monitoring tools can observe the principle of least privilege.\nAccess is also given by default to members of pg_monitor.\n\nAuthor: Nathan Bossart\nReviewed-by: Laurenz Albe\nDiscussion: https://postgr.es/m/92F458A2-6459-44B8-A7F2-2ADD3225046A@amazon.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/9cd92d1a33699f86aa53d44ab04cc3eb50c18d11"},{"sha":"7bda0a0dee9a2064947d97c85fadbb4638d51639","author":{"name":"Commitfest Bot","email":"b9e638e07cc2e2abf56c9c0cad7954f2e3bc1641@cputube.org"},"message":"[CF 20/1490] macOS Secure Transport SSL Support\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/20/1490\nPatch(es): https://www.postgresql.org/message-id/CE440587-6093-44F6-A3CA-D1AFE6392B9B@yesql.se\nAuthor(s): Daniel Gustafsson","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/7bda0a0dee9a2064947d97c85fadbb4638d51639"}]}
{"actor":{"display_login":"postgresql-cfbot"}}