{"push_id":3058189124,"size":6,"distinct_size":1,"ref":"refs/heads/commitfest/20/1204","head":"7d38ee041c0c4c4cc9c7e88b0210d89f524cda4e","before":"2c9299338e3cc66a7768a9b9d88997ea0a4fd5cc","commits":[{"sha":"3f2393edefa5ef2b6970a5a2fa2c7e9c55cc10cf","author":{"name":"Alvaro Herrera","email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org"},"message":"Redesign initialization of partition routing structures\n\nThis speeds up write operations (INSERT, UPDATE, DELETE, COPY, as well\nas the future MERGE) on partitioned tables.\n\nThis changes the setup for tuple routing so that it does far less work\nduring the initial setup and pushes more work out to when partitions\nreceive tuples.  PartitionDispatchData structs for sub-partitioned\ntables are only created when a tuple gets routed through it.  The\npossibly large arrays in the PartitionTupleRouting struct have largely\nbeen removed.  The partitions[] array remains but now never contains any\nNULL gaps.  Previously the NULLs had to be skipped during\nExecCleanupTupleRouting(), which could add a large overhead to the\ncleanup when the number of partitions was large.  The partitions[] array\nis allocated small to start with and only enlarged when we route tuples\nto enough partitions that it runs out of space. This allows us to keep\nsimple single-row partition INSERTs running quickly.  Redesign\n\nThe arrays in PartitionTupleRouting which stored the tuple translation maps\nhave now been removed.  These have been moved out into a\nPartitionRoutingInfo struct which is an additional field in ResultRelInfo.\n\nThe find_all_inheritors() call still remains by far the slowest part of\nExecSetupPartitionTupleRouting(). This commit just removes the other slow\nparts.\n\nIn passing also rename the tuple translation maps from being ParentToChild\nand ChildToParent to being RootToPartition and PartitionToRoot. The old\nnames mislead you into thinking that a partition of some sub-partitioned\ntable would translate to the rowtype of the sub-partitioned table rather\nthan the root partitioned table.\n\nAuthors: David Rowley and Amit Langote, heavily revised by Álvaro Herrera\nTesting help from Jesper Pedersen and Kato Sho.\nDiscussion: https://postgr.es/m/CAKJS1f_1RJyFquuCKRFHTdcXqoPX-PYqAd7nz=GVBwvGh4a6xA@mail.gmail.com","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/3f2393edefa5ef2b6970a5a2fa2c7e9c55cc10cf"},{"sha":"a7aa608e0f5910f9c73a530a66142c08e3d9043a","author":{"name":"Andres Freund","email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de"},"message":"Inline hot path of slot_getsomeattrs().\n\nThis yields a minor speedup, which roughly balances the loss from the\nupcoming introduction of callbacks to do some operations on slots.\n\nAuthor: Andres Freund\nDiscussion: https://postgr.es/m/20181105210039.hh4vvi4vwoq5ba2q@alap3.anarazel.de","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/a7aa608e0f5910f9c73a530a66142c08e3d9043a"},{"sha":"409231919443984635b7ae9b7e2e261ab984eb1e","author":{"name":"Alvaro Herrera","email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org"},"message":"pgbench: introduce a RandomState struct\n\nThis becomes useful when used to retry a transaction after a\nserialization error or deadlock abort.  (We don't yet have that feature,\nbut this is preparation for it.)\n\nWhile at it, use separate random state for thread administratrivia such\nas deciding which script to run, how long to delay for throttling, or\nwhether to log a message when sampling; this not only makes these tasks\nindependent of each other, but makes the actual thread run\ndeterministic.\n\nAuthor: Marina Polyakova\nReviewed-by: Fabien Coelho\nDiscussion: https://postgr.es/m/72a0d590d6ba06f242d75c2e641820ec@postgrespro.ru","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/409231919443984635b7ae9b7e2e261ab984eb1e"},{"sha":"0201d79a5549e3375ea5e5aee351378399453f15","author":{"name":"Alvaro Herrera","email":"3c84f0de6f8a0f296d36cdd9f57fa166641c96b1@alvh.no-ip.org"},"message":"Avoid re-typedef'ing PartitionTupleRouting\n\nApparently, gcc on macOS (?) doesn't like it.\n\nPer buildfarm.","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/0201d79a5549e3375ea5e5aee351378399453f15"},{"sha":"4da597edf1bae0cf0453b5ed6fc4347b6334dfe1","author":{"name":"Andres Freund","email":"883768b6dd2c42aea0031b24be8a2da40fef4b64@anarazel.de"},"message":"Make TupleTableSlots extensible, finish split of existing slot type.\n\nThis commit completes the work prepared in 1a0586de36, splitting the\nold TupleTableSlot implementation (which could store buffer, heap,\nminimal and virtual slots) into four different slot types.  As\ndescribed in the aforementioned commit, this is done with the goal of\nmaking tuple table slots extensible, to allow for pluggable table\naccess methods.\n\nTo achieve runtime extensibility for TupleTableSlots, operations on\nslots that can differ between types of slots are performed using the\nTupleTableSlotOps struct provided at slot creation time.  That\nincludes information from the size of TupleTableSlot struct to be\nallocated, initialization, deforming etc.  See the struct's definition\nfor more detailed information about callbacks TupleTableSlotOps.\n\nI decided to rename TTSOpsBufferTuple to TTSOpsBufferHeapTuple and\nExecCopySlotTuple to ExecCopySlotHeapTuple, as that seems more\nconsistent with other naming introduced in recent patches.\n\nThere's plenty optimization potential in the slot implementation, but\naccording to benchmarking the state after this commit has similar\nperformance characteristics to before this set of changes, which seems\nsufficient.\n\nThere's a few changes in execReplication.c that currently need to poke\nthrough the slot abstraction, that'll be repaired once the pluggable\nstorage patchset provides the necessary infrastructure.\n\nAuthor: Andres Freund and  Ashutosh Bapat, with changes by Amit Khandekar\nDiscussion: https://postgr.es/m/20181105210039.hh4vvi4vwoq5ba2q@alap3.anarazel.de","distinct":false,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/4da597edf1bae0cf0453b5ed6fc4347b6334dfe1"},{"sha":"7d38ee041c0c4c4cc9c7e88b0210d89f524cda4e","author":{"name":"Commitfest Bot","email":"b9e638e07cc2e2abf56c9c0cad7954f2e3bc1641@cputube.org"},"message":"[CF 20/1204] Implement NULL-related checks in object address functions to prevent cache lookup errors\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/1204\nPatch(es): https://www.postgresql.org/message-id/20180918055142.GK31460@paquier.xyz\nAuthor(s): Michael Paquier","distinct":true,"url":"https://api.github.com/repos/postgresql-cfbot/postgresql/commits/7d38ee041c0c4c4cc9c7e88b0210d89f524cda4e"}]}
{"actor":{"display_login":"postgresql-cfbot"}}