Heikki Linnakangas <hlinnakan...@vmware.com> writes: > [ unreviewed patches ]
> Grouping Sets > There has been a lot of discussion, but no decisions. See > http://www.postgresql.org/message-id/87vbodhtvb....@news-spur.riddles.org.uk. > Would a committer be interested to take responsibility of this? If not, > this will just linger indefinitely. I should and will take this, but not in this commitfest: I've been just horribly busy lately with both work and personal issues. If we can punt it to the next fest, I will promise to work on it then. > INNER JOIN removals > The latest patch is significantly different from what was originally > submitted for the commitfest, so I wouldn't feel bad just bumping this > to the next one. I'll do that unless someone picks this up soon. > Tom: I know you're busy with the more urgent jsonb patch.. Do you think > you would find the time to review this anytime soon? Anyone else? Same deal here. > Selectivity estimation for inet operators > I think there's a bug in the estimation of semi-joins, see > http://www.postgresql.org/message-id/5423dc8d.3080...@vmware.com. But I > think we could split this patch into two, and commit the non-join > selectivity estimator first, as that seems OK. If no-one else steps up > to the plate, I can do that.. And I'd like to look this one over too ... > Escaping from blocked send() by pg_terminate_backend(). > I've had a look, but I'd like to have a second opinion on this. I concur with your opinion that this is scary as heck. We need multiple pairs of eyeballs if we're going to do anything in this area. In the long run though, I think pushing functionality into signal handlers is exactly backwards; we ought to be trying to go the other way. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
