On Sat, Mar 7, 2009 at 9:35 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers