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