Thread: [HACKERS] Patches I'm thinking of pushing shortly
I have some patches sitting around in my workspace that I think are non-controversial, and so I was considering just pushing them once the tree opens for v11 development. If anyone thinks they need further review, I'll put them into the September commitfest, but otherwise we might as well skip the overhead. These are: 1. check-hash-bucket-size-against-work_mem-2.patch from https://www.postgresql.org/message-id/13698.1487283211@sss.pgh.pa.us That discussion sort of trailed off, but there wasn't really anyone saying not to commit it, and no new ideas have surfaced. 2. simplify-simple-expresssion-checking.patch from https://www.postgresql.org/message-id/2257.1498412915@sss.pgh.pa.us This is the patch to get rid of plpgsql's exec_simple_check_node() as Robert suggested. It's never been anything but a maintenance nuisance. 3. remove-pgbench-option-ordering-constraint.patch from https://www.postgresql.org/message-id/20559.1501703105@sss.pgh.pa.us That one was already informally reviewed by two people, so I don't think it needs another look. regards, tom lane
On Fri, Aug 11, 2017 at 11:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 3. remove-pgbench-option-ordering-constraint.patch from > https://www.postgresql.org/message-id/20559.1501703105@sss.pgh.pa.us > > That one was already informally reviewed by two people, so I don't > think it needs another look. I'd vote for putting this fix into v10, but maybe that's just me. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes: > On Fri, Aug 11, 2017 at 11:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 3. remove-pgbench-option-ordering-constraint.patch from >> https://www.postgresql.org/message-id/20559.1501703105@sss.pgh.pa.us >> >> That one was already informally reviewed by two people, so I don't >> think it needs another look. > I'd vote for putting this fix into v10, but maybe that's just me. ... OK by me, any objections? regards, tom lane
On Sat, Aug 12, 2017 at 3:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I have some patches sitting around in my workspace that I think are > non-controversial, and so I was considering just pushing them once > the tree opens for v11 development. If anyone thinks they need > further review, I'll put them into the September commitfest, but > otherwise we might as well skip the overhead. These are: > > 1. check-hash-bucket-size-against-work_mem-2.patch from > https://www.postgresql.org/message-id/13698.1487283211@sss.pgh.pa.us > > That discussion sort of trailed off, but there wasn't really anyone > saying not to commit it, and no new ideas have surfaced. +1 I'd vote for including this in v10. There doesn't seem to be any downside to this: it's a no brainer to avoid our exploding hash table case when we can see it coming. -- Thomas Munro http://www.enterprisedb.com
On 13/08/17 16:19, Thomas Munro wrote: > On Sat, Aug 12, 2017 at 3:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: [...] > > I'd vote for including this in v10. There doesn't seem to be any > downside to this: it's a no brainer to avoid our exploding hash table > case when we can see it coming. > But explosions are fun! < ducks, and runs away VERY rapidly> More seriously: Up to now I'd been avoiding hash indexes, so great news! Cheers, Gavin
Thomas Munro <thomas.munro@enterprisedb.com> writes: > On Sat, Aug 12, 2017 at 3:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 1. check-hash-bucket-size-against-work_mem-2.patch from >> https://www.postgresql.org/message-id/13698.1487283211@sss.pgh.pa.us > +1 > I'd vote for including this in v10. There doesn't seem to be any > downside to this: it's a no brainer to avoid our exploding hash table > case when we can see it coming. Anybody else want to vote that way? For myself it's getting a bit late in the beta process to be including inessential changes, but I'm willing to push it to v10 not just v11 if there's multiple people speaking for that. regards, tom lane
On Sun, Aug 13, 2017 at 5:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I'd vote for including this in v10. There doesn't seem to be any >> downside to this: it's a no brainer to avoid our exploding hash table >> case when we can see it coming. > > Anybody else want to vote that way? For myself it's getting a bit late > in the beta process to be including inessential changes, but I'm willing > to push it to v10 not just v11 if there's multiple people speaking for > that. I'd vote for waiting until v11. I think it's too late to be doing things that might change good plans into bad ones or visca versa; that's a recipe for having to put out 10.1 and 10.2 a little quicker than I'd like. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 2017-08-13 17:43:10 -0400, Robert Haas wrote: > On Sun, Aug 13, 2017 at 5:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> I'd vote for including this in v10. There doesn't seem to be any > >> downside to this: it's a no brainer to avoid our exploding hash table > >> case when we can see it coming. > > > > Anybody else want to vote that way? For myself it's getting a bit late > > in the beta process to be including inessential changes, but I'm willing > > to push it to v10 not just v11 if there's multiple people speaking for > > that. > > I'd vote for waiting until v11. I think it's too late to be doing > things that might change good plans into bad ones or visca versa; > that's a recipe for having to put out 10.1 and 10.2 a little quicker > than I'd like. Similar here, there doesn't seem to be that much urgency. - Andres
On Sun, Aug 13, 2017 at 11:43 PM, Robert Haas <robertmhaas@gmail.com> wrote:
-- On Sun, Aug 13, 2017 at 5:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'd vote for including this in v10. There doesn't seem to be any
>> downside to this: it's a no brainer to avoid our exploding hash table
>> case when we can see it coming.
>
> Anybody else want to vote that way? For myself it's getting a bit late
> in the beta process to be including inessential changes, but I'm willing
> to push it to v10 not just v11 if there's multiple people speaking for
> that.
I'd vote for waiting until v11. I think it's too late to be doing
things that might change good plans into bad ones or visca versa;
that's a recipe for having to put out 10.1 and 10.2 a little quicker
than I'd like.
+1 for waiting until v11 with it.
We have plenty enough other things that could end up needing a quick post-release-release, and those are things that have received at least somem testing...