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:

Previous
From: Bruce Momjian
Date:
Subject: New 6.5 Open Items list
Next
From: Bruce Momjian
Date:
Subject: Newer list