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 inf
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 ta
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 EXP
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 below
[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 i
On Apr 4, 2005, at 12:54 AM, Tom Lane wrote:
[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 bet
