Home > DBA, Oracle, SQL > Day 4: The Twelve Days of SQL: The way you write your query matters

Day 4: The Twelve Days of SQL: The way you write your query matters


On the fourth day of Christmas, my true love gave to me
Four colly birds.

Day 4: The way you write your query matters (Day 3: There isn’t always a single optimal query plan for a SQL query) (Day 5: The query cost is only an estimate)

Also see Performance comparison between CONNECT BY and recursive subquery factoring

As I mentioned in the first part of this series, SQL is a redundant language which allows you to specify the desired result in different ways. However, your choice may have a significant impact on efficiency. Here are some tests based on a 1988 paper by Fabian Pascal. The tests require a table called Personnel containing employee details and a table called Payroll containing salary payments. The employee ID is the primary key of each table (meaning that they are also indexed using the employee ID) and the payroll table is indexed using salary. The problem is to find out which one of the 9900 employees received a payment of $199,170. I conducted my tests using Oracle Database 11g Release 2 and the Developer Days Virtual Machine.

CREATE TABLE personnel
(
  empid CHAR(9),
  lname CHAR(15),
  fname CHAR(12),
  address CHAR(20),
  city CHAR(20),
  state CHAR(2),
  ZIP CHAR(5)
);

CREATE TABLE payroll
(
  empid CHAR(9),
  bonus INTEGER,
  salary INTEGER
);

INSERT INTO personnel
SELECT
  TO_CHAR(LEVEL, '09999') AS empid,
  DBMS_RANDOM.STRING('U', 15) AS lname,
  DBMS_RANDOM.STRING('U', 12) AS fname,
  '500 ORACLE PARKWAY' AS address,
  'REDWOOD SHORES' AS city,
  'CA' AS state,
  '94065' AS zip
FROM
  dual
CONNECT BY LEVEL <= 9900;

INSERT INTO payroll(empid, bonus, salary)
SELECT
  per.empid,
  0 as bonus,
  99170 + ROUND(DBMS_RANDOM.VALUE * 100000, -2) AS salary
FROM
  personnel per;

CREATE UNIQUE INDEX personnel_u1 ON personnel(empid);
CREATE UNIQUE INDEX payroll_u1 ON payroll(empid);
CREATE INDEX payroll_i1 ON payroll(salary);

EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname=>'HR', tabname=>'PERSONNEL');
EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname=>'HR', tabname=>'PAYROLL');

Observe that I gathered optimizer statistics for both tables although they are not strictly necessary for the tests that follow; a query optimizer can generate query plans even in the absence of statistics.

Relational algebra method

The first formulation uses the relational algebra method. The query optimizer drives from the payroll table to the personnel table, a good move.

SELECT DISTINCT per.empid, per.lname
FROM personnel per JOIN payroll pay ON (per.empid = pay.empid)
WHERE pay.salary = 199170;

EMPID     LNAME
--------- ---------------
 01836    KULGDTAFIIYUDIE
 04535    ZZNDFPAGHWQAVSV
 07751    EFBDSEXSBJUQJIF
 06679    CCAZNDOPKSKEQRS

SQL_ID  cx451qsx2qfcv, child number 0
-------------------------------------
SELECT DISTINCT per.empid, per.lname FROM personnel per JOIN payroll
pay ON (per.empid = pay.empid) WHERE pay.salary = 199170

Plan hash value: 3901981856

-----------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name         | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |
-----------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |              |      1 |        |       |    21 (100)|          |      4 |00:00:00.01 |      16 |
|   1 |  HASH UNIQUE                   |              |      1 |     10 |   410 |    21   (5)| 00:00:01 |      4 |00:00:00.01 |      16 |
|   2 |   NESTED LOOPS                 |              |      1 |        |       |            |          |      4 |00:00:00.01 |      16 |
|   3 |    NESTED LOOPS                |              |      1 |     10 |   410 |    20   (0)| 00:00:01 |      4 |00:00:00.01 |      12 |
|   4 |     TABLE ACCESS BY INDEX ROWID| PAYROLL      |      1 |     10 |   150 |    10   (0)| 00:00:01 |      4 |00:00:00.01 |       6 |
|*  5 |      INDEX RANGE SCAN          | PAYROLL_I1   |      1 |     10 |       |     1   (0)| 00:00:01 |      4 |00:00:00.01 |       2 |
|*  6 |     INDEX UNIQUE SCAN          | PERSONNEL_U1 |      4 |      1 |       |     0   (0)|          |      4 |00:00:00.01 |       6 |
|   7 |    TABLE ACCESS BY INDEX ROWID | PERSONNEL    |      4 |      1 |    26 |     1   (0)| 00:00:01 |      4 |00:00:00.01 |       4 |
-----------------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   5 - access("PAY"."SALARY"=199170)
   6 - access("PER"."EMPID"="PAY"."EMPID")

Uncorrelated subquery

The second formulation uses an uncorrelated subquery. Even though the form of the query suggests that the optimizer will drive from the personnel table to the payroll table, the optimizer instead chooses to drive the other way. It is also smart enough to realize that duplicate rows will not be introduced and it therefore dispenses with the deduplication operation seen in the previous execution plan.

SELECT per.empid, per.lname
FROM personnel per
WHERE per.empid IN (SELECT pay.empid
FROM payroll pay
WHERE pay.salary = 199170);

EMPID     LNAME
--------- ---------------
 01836    KULGDTAFIIYUDIE
 04535    ZZNDFPAGHWQAVSV
 06679    CCAZNDOPKSKEQRS
 07751    EFBDSEXSBJUQJIF

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  avhtrqsvaay7j, child number 0
-------------------------------------
SELECT per.empid, per.lname FROM personnel per WHERE per.empid IN
(SELECT pay.empid FROM payroll pay WHERE pay.salary = 199170)

Plan hash value: 3342999746

----------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                     | Name         | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |
----------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |              |      1 |        |       |    20 (100)|          |      4 |00:00:00.01 |      17 |
|   1 |  NESTED LOOPS                 |              |      1 |        |       |            |          |      4 |00:00:00.01 |      17 |
|   2 |   NESTED LOOPS                |              |      1 |     10 |   410 |    20   (0)| 00:00:01 |      4 |00:00:00.01 |      13 |
|   3 |    TABLE ACCESS BY INDEX ROWID| PAYROLL      |      1 |     10 |   150 |    10   (0)| 00:00:01 |      4 |00:00:00.01 |       7 |
|*  4 |     INDEX RANGE SCAN          | PAYROLL_I1   |      1 |     10 |       |     1   (0)| 00:00:01 |      4 |00:00:00.01 |       3 |
|*  5 |    INDEX UNIQUE SCAN          | PERSONNEL_U1 |      4 |      1 |       |     0   (0)|          |      4 |00:00:00.01 |       6 |
|   6 |   TABLE ACCESS BY INDEX ROWID | PERSONNEL    |      4 |      1 |    26 |     1   (0)| 00:00:01 |      4 |00:00:00.01 |       4 |
----------------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - access("PAY"."SALARY"=199170)
   5 - access("PER"."EMPID"="PAY"."EMPID")

Correlated subquery

The third formulation uses the relational calculus method. This time too, the query optimizer drives from the payroll table to the personnel table but this time it thinks that a deduplication operation is necessary.

SELECT per.empid, per.lname
FROM personnel per
WHERE EXISTS (SELECT *
  FROM payroll pay
  WHERE per.empid = pay.empid
  AND pay.salary = 199170);

EMPID     LNAME
--------- ---------------
 01836    KULGDTAFIIYUDIE
 04535    ZZNDFPAGHWQAVSV
 06679    CCAZNDOPKSKEQRS
 07751    EFBDSEXSBJUQJIF

SQL_ID  gdazhxm5xdu44, child number 0
-------------------------------------
SELECT per.empid, per.lname FROM personnel per WHERE EXISTS (SELECT *
FROM payroll pay   WHERE per.empid = pay.empid   AND pay.salary =
199170)

Plan hash value: 864898783

-----------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name         | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |
-----------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |              |      1 |        |       |    16 (100)|          |      4 |00:00:00.01 |      16 |
|   1 |  NESTED LOOPS                  |              |      1 |        |       |            |          |      4 |00:00:00.01 |      16 |
|   2 |   NESTED LOOPS                 |              |      1 |     10 |   410 |    16   (7)| 00:00:01 |      4 |00:00:00.01 |      12 |
|   3 |    SORT UNIQUE                 |              |      1 |     10 |   150 |    10   (0)| 00:00:01 |      4 |00:00:00.01 |       6 |
|   4 |     TABLE ACCESS BY INDEX ROWID| PAYROLL      |      1 |     10 |   150 |    10   (0)| 00:00:01 |      4 |00:00:00.01 |       6 |
|*  5 |      INDEX RANGE SCAN          | PAYROLL_I1   |      1 |     10 |       |     1   (0)| 00:00:01 |      4 |00:00:00.01 |       2 |
|*  6 |    INDEX UNIQUE SCAN           | PERSONNEL_U1 |      4 |      1 |       |     0   (0)|          |      4 |00:00:00.01 |       6 |
|   7 |   TABLE ACCESS BY INDEX ROWID  | PERSONNEL    |      4 |      1 |    26 |     1   (0)| 00:00:01 |      4 |00:00:00.01 |       4 |
-----------------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   5 - access("PAY"."SALARY"=199170)
   6 - access("PER"."EMPID"="PAY"."EMPID")

Scalar subquery in the WHERE clause

The fourth formulation uses a scalar subquery in the WHERE clause. Oracle performs the scalar subquery once for each employee in the payroll table which is terribly inefficient.

SELECT per.empid, per.lname
FROM personnel per
WHERE (SELECT pay.salary FROM payroll pay WHERE pay.empid = per.empid) = 199170;

EMPID     LNAME
--------- ---------------
 01836    KULGDTAFIIYUDIE
 04535    ZZNDFPAGHWQAVSV
 06679    CCAZNDOPKSKEQRS
 07751    EFBDSEXSBJUQJIF

SQL_ID  ddgmw1whng5ah, child number 0
-------------------------------------
SELECT per.empid, per.lname FROM personnel per WHERE (SELECT pay.salary
FROM payroll pay WHERE pay.empid = per.empid) = 199170

Plan hash value: 3607962630

-------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name       | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |            |      1 |        |       | 11133 (100)|          |      4 |00:00:01.74 |   10551 |
|*  1 |  FILTER                      |            |      1 |        |       |            |          |      4 |00:00:01.74 |   10551 |
|   2 |   TABLE ACCESS FULL          | PERSONNEL  |      1 |   9900 |   251K|    68   (0)| 00:00:01 |   9900 |00:00:00.13 |     204 |
|   3 |   TABLE ACCESS BY INDEX ROWID| PAYROLL    |   9900 |      1 |    15 |     2   (0)| 00:00:01 |   9900 |00:00:00.98 |   10347 |
|*  4 |    INDEX UNIQUE SCAN         | PAYROLL_U1 |   9900 |      1 |       |     1   (0)| 00:00:01 |   9900 |00:00:00.34 |     447 |
-------------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter(=199170)
   4 - access("PAY"."EMPID"=:B1)

Scalar subquery in the SELECT clause

The fifth formulation uses a scalar subquery in the SELECT clause. The query optimizer executed the scalar subquery once for each salary of 199170. Step 1 is executed for each row returned by step 3. The number of buffers reported for line 0 should therefore be 26 not 16.

SELECT DISTINCT pay.empid, (SELECT lname FROM personnel per WHERE per.empid = pay.empid)
FROM payroll pay
WHERE pay.salary = 199170;

EMPID     (SELECTLNAMEFRO
--------- ---------------
 01836    KULGDTAFIIYUDIE
 04535    ZZNDFPAGHWQAVSV
 07751    EFBDSEXSBJUQJIF
 06679    CCAZNDOPKSKEQRS

SQL_ID  6y4kznqkvq635, child number 0
-------------------------------------
SELECT DISTINCT pay.empid, (SELECT lname FROM personnel per WHERE
per.empid = pay.empid) FROM payroll pay WHERE pay.salary = 199170

Plan hash value: 750911849

---------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |
---------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |      1 |        |       |    11 (100)|          |      4 |00:00:00.01 |      16 |
|   1 |  TABLE ACCESS BY INDEX ROWID | PERSONNEL    |      4 |      1 |    26 |     2   (0)| 00:00:01 |      4 |00:00:00.01 |      10 |
|*  2 |   INDEX UNIQUE SCAN          | PERSONNEL_U1 |      4 |      1 |       |     1   (0)| 00:00:01 |      4 |00:00:00.01 |       6 |
|   3 |  HASH UNIQUE                 |              |      1 |     10 |   150 |    11  (10)| 00:00:01 |      4 |00:00:00.01 |      16 |
|   4 |   TABLE ACCESS BY INDEX ROWID| PAYROLL      |      1 |     10 |   150 |    10   (0)| 00:00:01 |      4 |00:00:00.01 |       6 |
|*  5 |    INDEX RANGE SCAN          | PAYROLL_I1   |      1 |     10 |       |     1   (0)| 00:00:01 |      4 |00:00:00.01 |       2 |
---------------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("PER"."EMPID"=:B1)
   5 - access("PAY"."SALARY"=199170)

Aggregate function to check existence

The sixth formulation uses the COUNT aggregate function to check existence. I obtained surprising results; the execution plan was terribly inefficient when the constant was placed on the right hand side of the condition but was superbly efficient when the constant was placed on the left hand side. The efficient result testifies to the power of the optimizer while the inefficient result testifies to its fallibility.

SELECT per.empid, per.lname
FROM personnel per
WHERE (SELECT count(*) FROM payroll pay WHERE pay.empid = per.empid AND pay.salary = 199170) > 0;

EMPID     LNAME
--------- ---------------
 01836    KULGDTAFIIYUDIE
 04535    ZZNDFPAGHWQAVSV
 06679    CCAZNDOPKSKEQRS
 07751    EFBDSEXSBJUQJIF

SQL_ID  9df084bq799p1, child number 0
-------------------------------------
SELECT per.empid, per.lname FROM personnel per WHERE (SELECT count(*)
FROM payroll pay WHERE pay.empid = per.empid AND pay.salary = 199170) >
0

Plan hash value: 3561519015

--------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                     | Name       | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |
--------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |            |      1 |        |       |  9970 (100)|          |      4 |00:00:01.71 |   10555 |
|*  1 |  FILTER                       |            |      1 |        |       |            |          |      4 |00:00:01.71 |   10555 |
|   2 |   TABLE ACCESS FULL           | PERSONNEL  |      1 |   9900 |   251K|    68   (0)| 00:00:01 |   9900 |00:00:00.09 |     204 |
|   3 |   SORT AGGREGATE              |            |   9900 |      1 |    15 |            |          |   9900 |00:00:01.20 |   10351 |
|*  4 |    TABLE ACCESS BY INDEX ROWID| PAYROLL    |   9900 |      1 |    15 |     2   (0)| 00:00:01 |      4 |00:00:00.73 |   10351 |
|*  5 |     INDEX UNIQUE SCAN         | PAYROLL_U1 |   9900 |      1 |       |     1   (0)| 00:00:01 |   9900 |00:00:00.27 |     451 |
--------------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter(>0)
   4 - filter("PAY"."SALARY"=199170)
   5 - access("PAY"."EMPID"=:B1)

SELECT per.empid, per.lname
FROM personnel per
WHERE 0 < (SELECT count(*) FROM payroll pay WHERE pay.empid = per.empid AND pay.salary = 199170);

EMPID     LNAME
--------- ---------------
 01836    KULGDTAFIIYUDIE
 04535    ZZNDFPAGHWQAVSV
 06679    CCAZNDOPKSKEQRS
 07751    EFBDSEXSBJUQJIF

SQL_ID  8bk6d3udbcbp4, child number 0
-------------------------------------
SELECT per.empid, per.lname FROM personnel per WHERE 0 < (SELECT
count(*) FROM payroll pay WHERE pay.empid = per.empid AND pay.salary =
199170)

Plan hash value: 864898783

-----------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name         | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |
-----------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |              |      1 |        |       |    16 (100)|          |      4 |00:00:00.01 |      16 |
|   1 |  NESTED LOOPS                  |              |      1 |        |       |            |          |      4 |00:00:00.01 |      16 |
|   2 |   NESTED LOOPS                 |              |      1 |     10 |   410 |    16   (7)| 00:00:01 |      4 |00:00:00.01 |      12 |
|   3 |    SORT UNIQUE                 |              |      1 |     10 |   150 |    10   (0)| 00:00:01 |      4 |00:00:00.01 |       6 |
|   4 |     TABLE ACCESS BY INDEX ROWID| PAYROLL      |      1 |     10 |   150 |    10   (0)| 00:00:01 |      4 |00:00:00.01 |       6 |
|*  5 |      INDEX RANGE SCAN          | PAYROLL_I1   |      1 |     10 |       |     1   (0)| 00:00:01 |      4 |00:00:00.01 |       2 |
|*  6 |    INDEX UNIQUE SCAN           | PERSONNEL_U1 |      4 |      1 |       |     0   (0)|          |      4 |00:00:00.01 |       6 |
|   7 |   TABLE ACCESS BY INDEX ROWID  | PERSONNEL    |      4 |      1 |    26 |     1   (0)| 00:00:01 |      4 |00:00:00.01 |       4 |
-----------------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   5 - access("PAY"."SALARY"=199170)
   6 - access("PAY"."EMPID"="PER"."EMPID")

Correlated subquery (double negative)

You may have thought to ask: how does one know for sure that all the above queries are equivalent. The answer is that one would have to convert them to a “canonical” form. All semantically equivalent queries would be converted into the same canonical form. It’s a mechanical chore that could be automated but unfortunately such an automation tool does not exist. Here are two more formulations with different query plans. Are they semantically equivalent to the previous queries?

SELECT per.empid, per.lname
FROM personnel per
WHERE NOT EXISTS (SELECT *
 FROM payroll pay
 WHERE pay.empid = per.empid
 AND pay.salary != 199170);

EMPID     LNAME
--------- ---------------
 01836    KULGDTAFIIYUDIE
 04535    ZZNDFPAGHWQAVSV
 06679    CCAZNDOPKSKEQRS
 07751    EFBDSEXSBJUQJIF

SQL_ID  ayvvv10ah456y, child number 0
-------------------------------------
SELECT per.empid, per.lname FROM personnel per WHERE NOT EXISTS (SELECT
*  FROM payroll pay  WHERE pay.empid = per.empid  AND pay.salary !=
199170)

Plan hash value: 103534934

----------------------------------------------------------------------------------------------------------------------------
| Id  | Operation            | Name      | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |
----------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |           |      1 |        |       |    80 (100)|          |      4 |00:00:00.71 |     241 |
|*  1 |  HASH JOIN RIGHT ANTI|           |      1 |     99 |  4059 |    80   (2)| 00:00:01 |      4 |00:00:00.71 |     241 |
|*  2 |   TABLE ACCESS FULL  | PAYROLL   |      1 |   9890 |   144K|    11   (0)| 00:00:01 |   9896 |00:00:00.06 |      37 |
|   3 |   TABLE ACCESS FULL  | PERSONNEL |      1 |   9900 |   251K|    68   (0)| 00:00:01 |   9900 |00:00:00.06 |     204 |
----------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("PAY"."EMPID"="PER"."EMPID")
   2 - filter("PAY"."SALARY"<>199170)

Uncorrelated subquery (double negative)

SELECT per.empid, per.lname
FROM personnel per
WHERE per.empid NOT IN (SELECT pay.empid
FROM payroll pay
WHERE pay.salary != 199170);

EMPID     LNAME
--------- ---------------
 01836    KULGDTAFIIYUDIE
 04535    ZZNDFPAGHWQAVSV
 06679    CCAZNDOPKSKEQRS
 07751    EFBDSEXSBJUQJIF

SQL_ID  67azvy1nw1am1, child number 0
-------------------------------------
SELECT per.empid, per.lname FROM personnel per WHERE per.empid NOT IN
(SELECT pay.empid FROM payroll pay WHERE pay.salary != 199170)

Plan hash value: 2202369223

-------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation               | Name      | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT        |           |      1 |        |       |    80 (100)|          |      4 |00:00:00.53 |     241 |
|*  1 |  HASH JOIN RIGHT ANTI NA|           |      1 |     99 |  4059 |    80   (2)| 00:00:01 |      4 |00:00:00.53 |     241 |
|*  2 |   TABLE ACCESS FULL     | PAYROLL   |      1 |   9890 |   144K|    11   (0)| 00:00:01 |   9896 |00:00:00.07 |      37 |
|   3 |   TABLE ACCESS FULL     | PERSONNEL |      1 |   9900 |   251K|    68   (0)| 00:00:01 |   9900 |00:00:00.06 |     204 |
-------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("PER"."EMPID"="PAY"."EMPID")
   2 - filter("PAY"."SALARY"<>199170)

Day 3: There isn’t always a single optimal query plan for a SQL query

Day 5: The query cost is only an estimate

Categories: DBA, Oracle, SQL
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: