Re: CF3+4 (was Re: Parallel query execution)

On 23.01.2013 20:44, Stephen Frost wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> For all of that, I'm not sure that people failing to seek consensus
>> before coding is really so much of a problem as you seem to think.
>
> For my part, I don't think the lack of consensus-finding before
> submitting patches is, in itself, a problem.

I feel the same. Posting a patch before design and consensus may be a 
huge waste of time for the submitter himself, but it's not a problem for 
others.

> The problem, imv, is that everyone is expecting that once they've
> written a patch and put it on a commitfest that it's going to get
> committed- and it seems like committers are feeling under pressure
> that, because something's on the CF app, it needs to be committed
> in some form.

I'm sure none of the committers have a problem rejecting a patch, when 
there's clear grounds for it. Rejecting is the easiest way to deal with 
a patch. However, at least for me, >50% of the patches in any given 
commitfest don't interest me at all. I don't object to them, per se, but 
I don't want to spend any time on them either. I can imagine the same to 
be true for all other committers too. If a patch doesn't catch the 
interest of any committer, it's going to just sit there in the 
commitfest app for a long time, even if it's been reviewed.

> As discussed, we really need to be ready to truely
> triage the remaining patch set, figure out who is going to work on what,
> and punt the rest til post-9.3.

FWIW, here's how I feel about some the patches. It's not an exhaustive list.

"Event Triggers: Passing Information to User Functions (from 2012-11)"
I don't care about this whole feature, and haven't looked at the patch.. 
Probably not worth the complexity. But won't object if someone else 
wants to deal with it.

"Extension templates"
Same as above.

"Checksums (initdb-time)"
I don't want this feature, and I've said that on the thread.

"Identity projection (partitioning)"
Nothing's happened for over a month. Seems dead for that reason.

"Remove unused targets from plan"
Same here.

"Store additional information in GIN index"
Same here.

"Index based regexp search for pg_trgm"
I'd like to see this patch go in, but it still needs a fair amount of 
work. Probably needs to be pushed to next commitfest for that reason.

"allowing privileges on untrusted languages"
Seems like a bad idea to me, for the reasons Tom mentioned on that thread.

"Skip checkpoint on promoting from streaming replication"
Given that we still don't have an updated patch for this, it's probably 
getting too late for this. Would be nice to see the patch or an 
explanation of the new design Simon's been working.

"Patch to compute Max LSN of Data Pages (from 2012-11)"
Meh. Seems like a really special-purpose tool. Probably better to put 
this on pgfoundry.

"logical changeset generation v4"
This is a boatload of infrastructure for supporting logical replication, 
yet we have no code actually implementing logical replication that would 
go with this. The premise of logical replication over trigger-based was 
that it'd be faster, yet we cannot asses that without a working 
implementation. I don't think this can be committed in this state.

"built-in/SQL Command to edit the server configuration file 
(postgresql.conf)"
I think this should be a pgfoundry project, not in core. At least for now.

"json generator function enhacements"
"Json API and extraction functions"
To be honest, I don't understand why the json datatype had to be 
built-in to begin with. But it's too late to object to that now, and if 
the datatype is there, these functions probably should be, too. Or could 
these be put into a separate "json-extras" extension? I dunno.

"psql watch"
Meh. In practice, for the kind of ad-hoc monitoring this would be useful 
for, you might as well just use "watch psql -c 'select ...' ". Yes, that 
reconnects for each query, but so what.

"plpgsql_check_function"
I don't like this in its current form. A lot of code that mirrors 
pl_exec.c. I think we'll have to find a way to somehow re-use the 
existing code for this. Like, compile the function as usual, but don't 
stop on error.

- Heikki