TODO items (was Re: [COMMITTERS] pgsql/src/include/nodes (execnodes.h)) - Mailing list pgsql-hackers

Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Tom, I only see one entry in TODO for this:
>     * -Fix memory leak for aggregates?

>> -----------------------------  Log Message  -----------------------------
>> Modify nodeAgg.c so that no rows are returned for a GROUP BY
>> with no input rows, per pghackers discussions around 7/22/99.  Clean up
>> a bunch of ugly coding while at it; remove redundant re-lookup of
>> aggregate info at start of each new GROUP.  Arrange to pfree intermediate
>> values when they are pass-by-ref types, so that aggregates on pass-by-ref
>> types no longer eat memory.  This takes care of a couple of TODO items...

Hmm, you are right --- I thought that discussion about changing the
semantics of aggregates with GROUP BY had made it to the TODO list,
but apparently it never did.  It should have, however: * When using aggregates + GROUP BY, no rows in should yield no
rowsout
 


This motivated me to grovel through the TODO list, which I hadn't done
for a while, and I have some updates/comments.


PARSER
------

* Select a[1] FROM test fails, it needs test.a[1]

Fixed for 6.6 --- actually same thing as next item,
* -Array index references without table name cause problems [array]

* Update table SET table.value = 3 fails

AFAICS, the SQL92 syntax allows only a bare <column name> as the
target of a SET clause.  Not sure it's worth expending any effort
on this one...

ENHANCEMENTS
------------

COMMANDS

* Generate error on CREATE OPERATOR of ~~, ~ and and ~*

"Error" seems a little strong, maybe a "NOTICE" along the lines of
"We trust you know that ~~ defines the behavior of the LIKE keyword".

I believe the original motivation for this entry was that the parser
would do the wrong thing for arbitrary operators named ~~ etc, because
it would try to apply optimizations that were only suitable for the
standard ops of those names (textlike etc).  That's no longer a problem,
because those optimizations are now triggered off matching of the
operator OID; they will not cause a problem if Joe User invents an
operator named ~~ for his spiffy new datatype.  But perhaps Joe should
be reminded that he just made LIKE applicable to his datatype.  Or maybe
that's not worth worrying about...

* Move LIKE index optimization handling to the optimizer

This is basically done, although I have a couple of cleanup issues
to take care of.

CLIENTS

* PQrequestCancel() be able to terminate backend waiting for lock

There is an equivalent item under MISC, and it doesn't seem like it
belongs under CLIENTS --- the necessary code change is in the backend.

MISC

* Do autocommit so always in a transaction block(?)

Huh?  What is this supposed to mean?

PERFORMANCE
-----------

INDEXES

* Convert function(constant) into a constant for index use

Done as of now; see Frankpitt's constant-expression simplifier.
We might have some lingering bugs with simplifying things that
ought not be simplified, however...

* Allow SELECT * FROM tab WHERE int2col = 4 use int2col index, int8 too[optimizer]

I believe float4 columns have the same sort of problem, since a numeric
constant will be taken as float8 not float4 if not explicitly casted.
For that matter, numeric/decimal columns do too, or would if we had
indexing support for them...

* Allow optimizer to prefer plans that match ORDER BY

This is done, although we now have the opposite problem: the darn thing
is too eager to pick an indexscan plan :-(.  Need to make the cost
estimates for indexscan vs explicit sort more accurate.

MISC

* Update pg_statistic table to remove operator column

I do not believe we should do this.  It's true that right now we have
no use for the operator column, because only the default '<' ordering
will ever be used by VACUUM, but we should keep the column in the name
of datatype extensibility.  Someday VACUUM might compute stats with
respect to more than one ordering, for datatypes that have more than one.

* -Fix memory exhaustion when using many OR's [cnfify]

cnfify is still pretty slow with many subclauses --- the behavior
is now O(N^2) rather than O(2^N), but that just means it's 
slow rather than intolerable.  I'm not sure what to do about it.
We probably need to be using heuristics instead of an unconditional
convert-to-normal-form-or-bust algorithm, but what should the
heuristic conditions be?  Am thinking about it, could use suggestions.

* Process const = const parts of OR clause in separate pass

Done --- Frankpitt's const simplifier handles this.

* change VACUUM ANALYZE to use btree comparison functions, not <,=,> calls

Didn't we decide this probably wasn't worth doing?

SOURCE CODE
-----------

* Remove SET KSQO option if OR processing is improved

You can put my name on this one --- I'm not quite ready to pull KSQO
but I think we are close.
        regards, tom lane