not using table aliases in where clause slow-down?

Started by Mark Cowlishawabout 25 years ago3 messagesgeneral
Jump to latest
#1Mark Cowlishaw
markc@ot.com.au

I noticed that running queries that do -not- use declared table aliases in
the 'where' clause seem to run a hell-of-a-lot slower than when aliases are
used. Is there a valid reason for this? It started out as a typo but now I'm
curious.

(7.0.3)

eg:

select
rel.release_id as rel_id, rel.code as rel_code,
subs.subsystem_id as subs_id, subs.code as subs_code,
func.function_id as func_id, func.code as func_code,
purp.purpose_id as purp_id, purp.code as purp_code,
purp.title as purp_title,
proc.procedure_id as proc_id, proc.code as proc_code,
proc.title as proc_title
from
releases as rel, subsystems as subs,
functions as func, purposes as purp, procedures as proc
where
rel.project_id = 53
and purp.release_id = rel.release_id
and purp.function_id = func.function_id
and func.subsystem_id = subs.subsystem_id
and purp.purpose_id = proc.purpose_id
order by
rel.code, subs.code, func.code,
purp.code, proc.code;

(runs pretty much instantly)

-versus-

select
rel.release_id as rel_id, rel.code as rel_code,
subs.subsystem_id as subs_id, subs.code as subs_code,
func.function_id as func_id, func.code as func_code,
purp.purpose_id as purp_id, purp.code as purp_code,
purp.title as purp_title,
proc.procedure_id as proc_id, proc.code as proc_code,
proc.title as proc_title
from
releases as rel, subsystems as subs,
functions as func, purposes as purp, procedures as proc
where
releases.project_id = 53
and purposes.release_id = releases.release_id
and purposes.function_id = functions.function_id
and functions.subsystem_id = subsystems.subsystem_id
and purposes.purpose_id = procedures.purpose_id
order by
rel.code, subs.code, func.code,
purp.code, proc.code;

(I get sick of waiting after > 30sec and ^C the query (in psql))

--
Mark Cowlishaw <markc@ot.com.au>
Open Telecommunications
1/116 Miller St. North Sydney
Phone: +61 2 8925 3192
Mobile: 0402 142 424

#2Richard Huxton
dev@archonet.com
In reply to: Mark Cowlishaw (#1)
Re: not using table aliases in where clause slow-down?

From: "Mark Cowlishaw" <markc@ot.com.au>

I noticed that running queries that do -not- use declared table aliases in
the 'where' clause seem to run a hell-of-a-lot slower than when aliases

are

used. Is there a valid reason for this? It started out as a typo but now

I'm

curious.

(7.0.3)

eg:

select

[snip]

from
releases as rel, subsystems as subs,
functions as func, purposes as purp, procedures as proc
where
rel.project_id = 53

[snip]

(runs pretty much instantly)

-versus-

select

[snip]

from
releases as rel, subsystems as subs,
functions as func, purposes as purp, procedures as proc
where
releases.project_id = 53

[snip]

(I get sick of waiting after > 30sec and ^C the query (in psql))

--
Mark Cowlishaw <markc@ot.com.au>

I think the second where refers to a different "releases" so it's equivalent
to doing a join without a joining condition (set product? can't remember -
need more coffee). I think it's the same as putting another "releases" in
"from" is what I'm trying to say (badly)

- Richard Huxton

#3Stephan Szabo
sszabo@megazone23.bigpanda.com
In reply to: Mark Cowlishaw (#1)
Re: not using table aliases in where clause slow-down?

On Mon, 19 Feb 2001, Mark Cowlishaw wrote:

I noticed that running queries that do -not- use declared table aliases in
the 'where' clause seem to run a hell-of-a-lot slower than when aliases are
used. Is there a valid reason for this? It started out as a typo but now I'm
curious.

Well, sort of. Technically the second query is invalid (you cannot use
the non-aliased name if you've aliased IIRC), but postgres assumes that
you really wanted additional from entries for the tables you are using
to make it valid, so:

select
rel.release_id as rel_id, rel.code as rel_code,
subs.subsystem_id as subs_id, subs.code as subs_code,
func.function_id as func_id, func.code as func_code,
purp.purpose_id as purp_id, purp.code as purp_code,
purp.title as purp_title,
proc.procedure_id as proc_id, proc.code as proc_code,
proc.title as proc_title
from
releases as rel, subsystems as subs,
functions as func, purposes as purp, procedures as proc
where
releases.project_id = 53
and purposes.release_id = releases.release_id
and purposes.function_id = functions.function_id
and functions.subsystem_id = subsystems.subsystem_id
and purposes.purpose_id = procedures.purpose_id
order by
rel.code, subs.code, func.code,
purp.code, proc.code;

is really:

select
rel.release_id as rel_id, rel.code as rel_code,
subs.subsystem_id as subs_id, subs.code as subs_code,
func.function_id as func_id, func.code as func_code,
purp.purpose_id as purp_id, purp.code as purp_code,
purp.title as purp_title,
proc.procedure_id as proc_id, proc.code as proc_code,
proc.title as proc_title
from
releases as rel, subsystems as subs,
functions as func, purposes as purp, procedures as proc,
***
releases, functions, subsystems, purposes, procedures
***
where
releases.project_id = 53
and purposes.release_id = releases.release_id
and purposes.function_id = functions.function_id
and functions.subsystem_id = subsystems.subsystem_id
and purposes.purpose_id = procedures.purpose_id
order by
rel.code, subs.code, func.code,
purp.code, proc.code;

which is a much different query