Re: [HACKERS] 6.5 TODO list - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: [HACKERS] 6.5 TODO list |
Date | |
Msg-id | 199905102201.SAA15406@candle.pha.pa.us Whole thread Raw |
In response to | Re: [HACKERS] 6.5 TODO list (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: [HACKERS] 6.5 TODO list
Re: [HACKERS] 6.5 TODO list Re: [HACKERS] 6.5 TODO list |
List | pgsql-hackers |
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > > OK, here is the list. Please send me changes. > > > Can not insert/update oid > > I think this is very unlikely to get fixed for 6.5, might as well just > put it on the to-do-later list. Moved. > > > EXPLAIN SELECT 1 UNION SELECT 2 crashes, rewrite system? > > Already fixed, I believe, unless someone can produce a case that > fails... Good. Thanks. > > > move UNION stuff into rewrite files > > Is this the same as EXPLAIN issue above, or a different concern? That is for me. I currently do UNION in postgres.c, shoud perhaps move to rewrite system. Not sure yet. > > > Vacuum of tables >2 gigs - NOTICE: Can't truncate multi-segments relation > > This is definitely a "must fix" item for 6.5, IMHO... Yes. It shows we are getting bigger. Most/all? of my commerical database clients don't have 2-gig tables. > > > missing optimizer selectivities for date, etc. > > The selectivity-estimation code needs major work. Again, I'd say just > shove it to the 6.6 list... Moved. > > > int8 indexing needs work? > > Is this done, or are there still problems? Not sure. Just asking. I saw Thomas complaining about some testing problems. Let's what he says. > > > hash on int2/char only looks a first bytes, and big-endian machines hash poorly > > Fixed. Removed. > > Some CASE() statements involving two tables crash > > Fixed. Good. > > CREATE FUNCTION fails > > Isn't this fixed? I wasn't aware of any remaining problems... OK. > > > Make sure pg_internal.init generation can't cause unreliability > > ... > > pg_interal.init, check for reliability on rebuild > > Duplicate items, I think. Yes. > > > GROUP BY expression? > > I think I've fixed the problems here. Removed. > > > problem with ALTER TABLE on inherited > > ... > > ALTER TABLE ADD COLUMN to inherited table put column in wrong place > > Duplicates? Yes. > > GROUP BY can reference columns not in target list > > What's wrong with that? Is that not a problem. What possible use would GROUP BY on columns not in target list be of use. Maybe it is. I remember someone asking for something like this. I will remove the item unless someone complains. I thought you were the one complaining about it. > > > SELECT name, value FROM t1 as touter WHERE (value/(SELECT AVG(value) > > FROM t1 WHERE name = touter.name)) > 0.75; fails > > Fixed. Already removed. Thanks for the updates. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
pgsql-hackers by date: