Welcome to dbFreaks.com!
FAQFAQ      ProfileProfile    Private MessagesPrivate Messages   Log inLog in

HAVING and WHERE clauses: Performance considerations in SQL

 
   Database Help (Home) -> DB2 RSS
Next:  what am I missing? (arrrays)  
Author Message
Jack

External


Since: Oct 08, 2008
Posts: 3



(Msg. 1) Posted: Wed Oct 08, 2008 6:20 am
Post subject: HAVING and WHERE clauses: Performance considerations in SQL
Archived from groups: comp>databases>ibm-db2 (more info?)

Hi,

Performance-wise, is there a difference between these 2 clauses?
I assume a large database...

1) With the WHERE clause:

Select FLD1, FLD2, FLD3
From myFile
Where FLD1 = 1 And FLD2 = 1
Group By FLD1, FLD2, FLD3

2) With the HAVING clause:

Select FLD1, FLD2, FLD3
From myFile
Group By FLD1, FLD2, FLD3
Having FLD1 = 1 And FLD2 = 1

thx

Jack

 >> Stay informed about: HAVING and WHERE clauses: Performance considerations in SQL 
Back to top
Login to vote
--CELKO--

External


Since: Jan 11, 2008
Posts: 974



(Msg. 2) Posted: Wed Oct 08, 2008 9:35 am
Post subject: Re: HAVING and WHERE clauses: Performance considerations in SQL [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

First of all, I hope that you know that fields are not anything like
columns and tables are not anything like files. Please tell me that
this was just an unfortunate bunch of data element names and not how
you think of data.

1) With the WHERE clause:

SELECT fld1, fld2, fld3
FROM MyFile
WHERE fld1 = 1
AND fld2 = 1
GROUP BY fld1, fld2, fld3;

The query is to act as if the WHERE clause is done first on the table
named (ugh!) MyFile. Then the resulting work set is grouped --
subsets of rows are reduced to a single row.

That is the model, but the optimizer is free to do this any way it
wants to do it. But since you violated the basic SQL Newsgroup
netiquette, and did not show us any DDL, we have no idea if there is
UNIQUE constraint on any of the columns, what the indexing is, etc.

But a smart optimizer will see the GROUP BY and that fld1 and fld2 are
constants, so we need "buckets" for the fld3 values. If fld3 is
indexed, then we know those values! That means looking at just the
index. Should be fast!

2) With the HAVING clause:

SELECT fld1, fld2, fld3
FROM MyFile
GROUP BY fld1, fld2, fld3
HAVING fld1 = 1
AND fld2 = 1;

This query is to act as if we make all possible groupings of (fld1,
fld2, fld3) in a working table, then applied the having clause.

That is the model, but the optimizer is free to do this any way it
wants to do it. But since you violated the basic SQL Newsgroup
netiquette, and did not show us any DDL, we have no idea if there is
UNIQUE constraint on any of the columns, what the indexing is, etc.

But a smart optimizer will see constants in the HAVING and convert
them into a WHERE clause. The two queries should work out about the
same.

 >> Stay informed about: HAVING and WHERE clauses: Performance considerations in SQL 
Back to top
Login to vote
Mark A

External


Since: Aug 29, 2008
Posts: 32



(Msg. 3) Posted: Wed Oct 08, 2008 9:14 pm
Post subject: Re: HAVING and WHERE clauses: Performance considerations in SQL [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

"Jack" <jacquestardif.TakeThisOut@gmail.com> wrote in message
news:3b4b3050-0836-4ee1-9958-ac0382cfb043@i20g2000prf.googlegroups.com...
> Hi,
>
> Performance-wise, is there a difference between these 2 clauses?
> I assume a large database...
>
> 1) With the WHERE clause:
>
> Select FLD1, FLD2, FLD3
> From myFile
> Where FLD1 = 1 And FLD2 = 1
> Group By FLD1, FLD2, FLD3
>
> 2) With the HAVING clause:
>
> Select FLD1, FLD2, FLD3
> From myFile
> Group By FLD1, FLD2, FLD3
> Having FLD1 = 1 And FLD2 = 1
>
> thx
>
> Jack

Generally speaking, the sooner you filter the rows, the less work DB2 will
need to do. That means filtering out the rows in where clause will generally
be faster, or at least not slower.
 >> Stay informed about: HAVING and WHERE clauses: Performance considerations in SQL 
Back to top
Login to vote
Display posts from previous:   
Related Topics:
Another way to write this with WINDOW clauses - This is a classic design flaw where someone failed to model durations with (start, end) temporal pairs and need to fix it: CREATE TABLE Foobar (event_date DATET NOT NULL PRIMARY KEY, vague_object CHAR(2) NOT NULL); INSERT INTO Foobar VALUES..

Views & performance - Hi, simple question I have 2 hugge tables Table A and Table B. I define a view over these 2 tables (select,..joint,...) My question is: Does the DB2 runs the query every time that I access the View? or only the first time that I create the view. Is th...

HADR performance issue - Hi, I have setup a HADR between two servers in different locations. When I compare the application response time in standard environment and in HADR environment, I find the latter is more than twice slower than the former. I have tried to tune some..

performance of db2 7 on mainframe - hello, I'm having a performance issue with a Windows CLI/ODBC application that connects to a DB2 rel 7.1 on a mainframe of a bank. I have to say I'm pretty new with this kind of environment. The application is working, but it is much slower than when I..

Performance Goals for DBAs - I would like to know what would be some performance goals for DBAs ? I can think of customer satisfaction and database availability being some. What else can I have as performance goals for my DBAs and more important what can I have as some stretch goals...
   Database Help (Home) -> DB2 All times are: Pacific Time (US & Canada) (change)
Page 1 of 1

 
You can post new topics in this forum
You can reply to topics in this forum
You can edit your posts in this forum
You can delete your posts in this forum
You can vote in polls in this forum



[ Contact us | Terms of Service/Privacy Policy ]