Noticed this problem,too.
You can always make the calculation you want done once inside a set
returning function so it'll behave like a table, but that's ugly.
On Mon, 28 Mar 2005 16:14:44 +0200, Hannes Dorbath
[EMAIL PROTECTED] wrote:
hm, a few days and not a single reply :|
any more
On Tue, Mar 29, 2005 at 01:48:48 -0700,
Karim A Nassar [EMAIL PROTECTED] wrote:
For this FK check, there only need be one referring id to invalidate the
delete. ISTM that for any delete with a FK reference, the index could
always be used to search for a single value in the referring table
On Tue, Mar 29, 2005 at 14:21:13 +0300,
ALÝ ÇELÝK [EMAIL PROTECTED] wrote:
I have used coalesce function for null fields but coalesce is too slow.
I need fast alternative for coalesce
It is unlikely that coalesce is your problem. People might be able to provide
some help if you provide
Hello!
I posted a similar question to this one about a month ago; but, for some
reason, it never seemed to be broadcast eventhough it ended up in the
archives. So, since I'm still struggling with this, I thought I'd
repost...
I'm trying to optimize a query and the EXPLAIN ANALYZE (see link
[EMAIL PROTECTED] writes:
I'm trying to optimize a query and the EXPLAIN ANALYZE (see link below)
shows that some hash join row estimates are wrong by a factor of 2-3,
and upwards of 7-8.
I doubt that improving those estimates would lead to markedly better
results. You need to think about
