{"ref":"refs/heads/master","push_id":55212851,"commits":[{"sha":"472d3935a2793343e450ba7cda4adbc323a984c3","author":{"email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us","name":"Tom Lane"},"url":"https://api.github.com/repos/postgres/postgres/commits/472d3935a2793343e450ba7cda4adbc323a984c3","message":"Rethink representation of index clauses' mapping to index columns.\n\nIn commit e2c2c2e8b1df7dfdb01e7e6f6191a569ce3c3195 I made use of nested\nlist structures to show which clauses went with which index columns, but\non reflection that's a data structure that only an old-line Lisp hacker\ncould love.  Worse, it adds unnecessary complication to the many places\nthat don't much care which clauses go with which index columns.  Revert\nto the previous arrangement of flat lists of clauses, and instead add a\nparallel integer list of column numbers.  The places that care about the\npairing can chase both lists with forboth(), while the places that don't\ncare just examine one list the same as before.\n\nThe only real downside to this is that there are now two more lists that\nneed to be passed to amcostestimate functions in case they care about\ncolumn matching (which btcostestimate does, so not passing the info is not\nan option).  Rather than deal with 11-argument amcostestimate functions,\npass just the IndexPath and expect the functions to extract fields from it.\nThat gets us down to 7 arguments which is better than 11, and it seems\nmore future-proof against likely additions to the information we keep\nabout an index path."}],"head":"472d3935a2793343e450ba7cda4adbc323a984c3","size":1}