Query Approach and performance
Hey everyone,
On average, are multiple simple queries better performance-wise than joins?
i.e.
select A.col1 from table1 A
select B.col2 from table2 B where B.col1 = A.col1
etc
vs
select A.col1, B.col2 from table1 A, table2 B where B.col1 = A.col1
Are joins better for small/large numbers of tables?
Is there a diff?
My approach to date has been to keep queries as simple as possible, and
when I see a need for complicated joins, I create a view and then do simple
queries against that.
Does pg cache queries like Oracle does so that repeated queries don't need
to go through the compile phase and run faster? Is this configurable?
Thanks,
Morgan
On Fri, Aug 17, 2001 at 03:29:36AM -0400, Morgan Curley wrote:
Hey everyone,
On average, are multiple simple queries better performance-wise than joins?
i.e.
select A.col1 from table1 A
select B.col2 from table2 B where B.col1 = A.col1
etcvs
select A.col1, B.col2 from table1 A, table2 B where B.col1 = A.col1
Are joins better for small/large numbers of tables?
Is there a diff?
Letting the database do joins is always better than doing them yourself.
My approach to date has been to keep queries as simple as possible, and
when I see a need for complicated joins, I create a view and then do simple
queries against that.
I don't think it makes that much difference. Views are precompiled to some
extend.
Does pg cache queries like Oracle does so that repeated queries don't need
to go through the compile phase and run faster? Is this configurable?
Hmm, I've never noticed that query compilation actually took any noticable
time. No, postgres doesn't do that but I'm not convinced it would make a
difference.
HTH,
--
Martijn van Oosterhout <kleptog@svana.org>
http://svana.org/kleptog/
Show quoted text
It would be nice if someone came up with a certification system that
actually separated those who can barely regurgitate what they crammed over
the last few weeks from those who command secret ninja networking powers.