Just curious, what is wrong with the first way of coding the solution?
--( Forwarded letter 1 follows )-
Date: Fri, 8 Oct 2004 08:44:23 +0400
To: Thomas.F.O'[EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTE
O CHRIS HOOVER έγραψε στις Oct 8, 2004 :
> Just curious, what is wrong with the first way of coding the solution?
> --( Forwarded letter 1 follows )-
> Date: Fri, 8 Oct 2004 08:44:23 +0400
> To: Thomas.F.O'[EMAIL PROTECTED], [EMAIL PROTECTED]
> Cc: [EMAIL PROTEC
I think the OUTER JOIN version is probably more efficient, but EXPLAIN
would tell you.
-tfo
On Oct 8, 2004, at 8:02 AM, CHRIS HOOVER wrote:
Just curious, what is wrong with the first way of coding the solution?
--( Forwarded letter 1 follows )-
Date: Fri, 8 Oct
Thomas F.O'Connell wrote:
I think the OUTER JOIN version is probably more efficient, but EXPLAIN
would tell you.
Well, this all makes me feel better. For everyone's edification:
select registration_id FROM registrations
where registration_id not in (select registration_id from receipts);
Generates
Friends,
How to get a the records returned by a sql executed within a pl/pgsql function
Sreejith
---(end of broadcast)---
TIP 8: explain analyze is your friend
On Fri, Oct 08, 2004 at 11:21:25PM +0530, sreejith s wrote:
> How to get a the records returned by a sql executed within a pl/pgsql function
It's not clear what you're asking, but perhaps one of the following
pages will answer your question:
http://www.postgresql.org/docs/7.4/static/plpgsql-stat
Michelle Murrain <[EMAIL PROTECTED]> writes:
> The OUTER JOIN version is quite a bit more efficient (by an order of magnitude)
> than the option with WHERE NOT EXISTS subquery.
This is going to be heavily dependent on the version of postgres. IN/NOT IN
execution has improved a lot in 7.4 and lat
Hey folks (long email, my apologies),
I am wrapping up my schema upgrade, and I just noticed a real
show-stopper for me... Here is the "before" table structure:
email_id | integer | not null
joejob| boolean | default false
bayes
"C. Bensend" <[EMAIL PROTECTED]> writes:
>Is it the addition of the multiple foreign keys that is slowing this
> down so much?
Foreign keys have zero, nada, zilch to do with the performance of
count(*). The only plausible theory I can think of for the performance
difference is that in your "n
> Foreign keys have zero, nada, zilch to do with the performance of
> count(*).
OK, I just wanted to make sure.
> The only plausible theory I can think of for the performance
> difference is that in your "new" database the table has been through
> several mass updates, leading to a whole lot of
10 matches
Mail list logo
