On Sat, Mar 7, 2009 at 9:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> * 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.
How do we get past that question?
>> * 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.
So are you going to do that and commit it, or do you want them to
rework it further?
...Robert
