Re: status of remaining patches

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: status of remaining patches
Date: 2009-03-08 05:14:44
Message-ID: 603c8f070903072114l7f555d20v3d270a61757b82e1@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Mar 7, 2009 at 9:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2009-03-08 06:09:02 Re: Out parameters handling
Previous Message Robert Haas 2009-03-08 05:03:51 Re: status of remaining patches