Re: status of remaining patches - Mailing list pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:
> [ much snipped ]

> * GIN fast insert.  Tom Lane committed some planner changes that make
> it possible for an AM to not support index scans, and posted the
> remaining patch.  No one other than me has spoken in favor of retaing
> support for index scans, so maybe Teodor should just apply the rest of
> this (perhaps with the minor wordsmithing I suggested in the second
> message linked below, or something similar).  Or if not, then we
> should decide that this will wait for 8.5 - it's time to fish or cut
> bait.

My feeling about it is that the insert speed improvement is worth
the loss of simple indexscan support.  Perhaps in 8.5 or later we can
think of some reasonable approach that will let simple indexscans be
put back into GIN, but there's not time left for that for 8.4.

I'm not sure the patch is actually ready to commit --- the documentation
certainly needs more work, and I've not read any of the code except for
the planner bits.  But I think it's probably close, if we can get past
this basic question of what the scope of the patch is.

> * Improve Performance of Multi-Batch Hash Join for Skewed Data Sets.
> Tom Lane reviewed this patch, and Ramon Lawrence responded, but it's
> not clear to me where we go from here.

I don't think this one is that far away either.  I've been holding Bryce
and Ramon's feet to the fire on the issue of possible downside, but so
far there's not really much evidence of any *actual* as opposed to
theoretical downside.  What bothers me more after having looked at the
patch is that it's got the executor taking decisions that rightfully
belong in the planner (mainly because the planner should know whether
IM will be used in order to assign a correct cost estimate).  That
probably won't take much work to fix though, it's just moving some code
and creating more path/plan node fields to carry the results.

> * Proposal of PITR performance improvement. Fujii Masao posted an
> updated version of this patch.  I believe it has yet to be reviewed by
> a committer.

Has it been reviewed by anybody?  There's no trace of reviewing work
on the commitfest page.  Personally I've been ignoring it on the
assumption that someone else should review it first.

> * Reducing some DDL Locks to ShareLock.  A substantial part of this
> was committed, and there hasn't been a new version of this patch in
> three months, so I think it should be bounced at this point.  But I
> don't want to do that myself unless someone at least makes some kind
> of noise of agreement.  Can I get a +1, or two?

Certainly Simon has been given more than enough time to do something
about this patch.  It should probably go to "returned with feedback"
until a new version does surface.  (IIRC, the part that got committed
was just some minor catalog infrastructure tweaking, it wasn't
substantial in terms of addressing the real goals of the patch.)
        regards, tom lane