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

> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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 rows out

Added to TODO, with a completion mark.

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

Good. It is a long list.

> 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]

Done.

>
> * 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...

Marked now as:

* Update table SET table.value = 3 fails(SQL standard says this is OK)

>
> 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...

Removed. You are correct that the message describes the old LIKE
optimization of user ~~ functions. This item is removed.

>
> * Move LIKE index optimization handling to the optimizer
>
> This is basically done, although I have a couple of cleanup issues
> to take care of.

Marked as done.

>
> 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.

Removed. Already present, as you mentioned.

>
> MISC
>
> * Do autocommit so always in a transaction block(?)
>
> Huh? What is this supposed to mean?

Some people want the SQL session to start inside a transaction, and you
have to explicity use COMMIT, at which point you are in a new
transaction that lasts until the next commit. Ingres SQL does this, and
it is a pain, I think.

>
> 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...

Marked as done.

>
> * 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...

Added new types to list.

>
> * 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.

That is amusing. Marked as done.

>
> 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.

Removed from the list.

>
> * -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.

Marked as done. Let's see if people complain.

>
> * Process const = const parts of OR clause in separate pass
>
> Done --- Frankpitt's const simplifier handles this.

Marked as done.

>
> * change VACUUM ANALYZE to use btree comparison functions, not <,=,> calls
>
> Didn't we decide this probably wasn't worth doing?
>

Yes. Removed.

> 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.

Marked for you. New TODO copy installed.

--
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