From: | "Vadim B(dot) Mikheev" <vadim(at)sable(dot)krasnoyarsk(dot)su> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | PostgreSQL-development <hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Open 6.3 issues |
Date: | 1998-02-22 12:18:23 |
Message-ID: | 34F0178F.48CBC102@sable.krasnoyarsk.su |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
>
> ORDER BY NULLs problem?
Hadn't time to look, yet...
> optimizer memory exhaustion with many OR's
I reported that it can't be fixed for 6.3 - please, move it into
TODO now. Nevertheless, I could apply patch to prepqual.c to
free memory whenever it's possible...
> Is GROUP BY duplicates fixed?
I got two reports that current code is OK - remove it.
> Do we have a self-join optimizer performance problem?
Yes. Not sure that I'll have time...
> Do we have a problem with GROUP BY without ORDER BY?
^^^^^^^
Could you remind what the problem is ?
> Problem with tables >2Gb
I still suggest to add elog(ERROR) to mdextend()...
> Can we improve vacuum locking issues?
I would leave vacuum as is. Improving of vacuum was on my 6.3 TODO
list - it's 6.4 TODO now :)
> 'Can not write block blind' error on createdb and regression collision
I'm fixing buffer manager now...
> subselect issues, NOT IN (empty query)
Closed: NOT IN (empty) and all others Op ALL (empty) now
returns TRUE.
> Check triggers regression test(Vadim)
Fixed already.
> Check select_views regression test
Results can't be identical on all platforms => change second query with
SELECT name, #thepath FROM iexit ORDER BY 1, 2;
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | D'Arcy J.M. Cain | 1998-02-22 14:18:49 | Re: [HACKERS] Tcl Implementation of crypt() |
Previous Message | Maurice Gittens | 1998-02-22 11:51:55 | Re: [HACKERS] How To free resources used by large object Relations? |