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

Heikki,

* Heikki Linnakangas (hlinnakangas@vmware.com) wrote:
> FWIW, here's how I feel about some the patches. It's not an exhaustive list.

Thanks for going through them and commenting on them.

> "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.

I'd like to see it happen.

> "Extension templates"
> Same as above.

This one isn't actually all that complex, though it does add a few
additional catalogs for keeping track of things.  For my part, I'd like
to see this go in as I see it being another step closer to Packages that
a certain other RDBMS has.

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

I see a lot of value in this.

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

I don't think this is dead..

> "Remove unused targets from plan"
> Same here.
>
> "Store additional information in GIN index"
> Same here.

Havn't been following these so not sure.  Some of these are in a state
of lack of progress for having not been reviewed.

> "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.

Agreed.

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

On the fence about this one.  I like the idea of reducing the need to be
a superuser, but there are risks associated with this change also.

> "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.

Agreed on these two.

> "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.

Andres had a working implementation of logical replication, with code to
back it up and performance numbers showing how much faster it is, at
PGCon last year, as I recall...  Admittedly, it probably needs changing
and updating due to the changes which the patches have been going
through, but I don't think the claim that we don't know it's faster is
fair.

> "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.

I don't think it would ever get deployed or used then..

> "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.

There were good reasons to add json as a data type, I thought, though I
don't have them offhand.

> "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.

I do that pretty often.  A better approach, imv, would be making psql a
bit more of a 'real' shell, with loops, conditionals, better variable
handling, etc.

> "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.

Havn't looked at this yet, but your concerns make sense to me.
Thanks!
    Stephen