From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] 6.5 TODO list |
Date: | 1999-05-10 22:01:18 |
Message-ID: | 199905102201.SAA15406@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-05-10 22:02:06 | New 6.5 Open Items list |
Previous Message | Tom Lane | 1999-05-10 21:55:23 | Re: [HACKERS] Re: [SQL] plpgsql error |