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