... A LITTLE IDEA TO OPTIMIZE SELECT STATEMENT - Mailing list pgsql-sql
From | Nicola Cisternino |
---|---|
Subject | ... A LITTLE IDEA TO OPTIMIZE SELECT STATEMENT |
Date | |
Msg-id | 38A827FB.1E048911@tin.it Whole thread Raw |
List | pgsql-sql |
Hello .... and excuse me for the language !!.. I've used C-ISAM filesystem structure for 15 years and i know very well "low-level" use of B-TREE access. Now i'm testing "Postgres" capabilities with great interest and i should want propose you a simple technique to optimize the SELECT statement that i always use in my querying code. My question is: why the Postgres Engine NOT USE index when some key segment of it aren't "complete" ???? ..... it's POSSIBLE !! I will try to explain you my idea with an example: I'm created a simply table "test": CREATE table test(F1 int(10), F2 char(10), F3 char(10)); ..after i've created a primary key and a "secondary" index: CREATE UNIQUE INDEX key1 on test (F1) CREATE INDEX key2 on test(F2, F3) ... now i've populated my table with 500,000 records ..... F1 F2 F3 ----------------------------------------------------- 1 A b 2 A f 3 A m <------ !! 4 A t ..... ..... ..... 100 C g 101 C l 102 C m <------ !! 103 C o 104 C r ....... ...... ...... 800 F a 801 F d 802 F f 803 F m <------ !! 804 F n 805 F q .......... 499994 H d 499995 H h 499996 H i 499997 H m <------ !! 499998 H p 499999 H v 500000 H x If i want all records that have the third field (F3) equal "m" i compose the query: SELECT * from test WHERE F3='m' ... with this query the SQL Engine MUST USE key2 index !!! (becouse F3 is included in this key!) and QUICKLY SKIP invalid records forcing a new value in F3 field and "restarting" with it ........ The steps are: 1) start with a "clean" key2 (F2="blank" and F3="blank") and read record n. 1 (1,A,b) 2) force "m" value in F3 field (becouse current value "b" is less then "m" !) and quickly point record n.3 3) read next record (rec -> 4/A/t) 4) force an "FF" hexadecimal value in F3 field (becouse current value "t" is greater then "m") and quickly point record n.100 5) force "m" value in F3 field (becouse current value "g" is less then "m" !) and quickly point record n.102 6) read next record (rec -> 103/C/o) 7) force an "FF" hexadecimal value in F3 field (becouse current value "o" is greater then "m") and quickly point record n.800 8) force "m" value in F3 field (becouse current value "a" is less then "m" !) and quickly point record n.803 9) read next record (rec -> 804/F/n) 10) force an "FF" hexadecimal value in F3 field (becouse current value "n" is greater then "m") and quickly point record n.499994 ( !!!) 11) force "m" value in F3 field (becouse current value "d" is less then "m" !) and quickly point record n.499997 12) read next record (rec -> 499998/F/n) 13) force an "FF" hexadecimal value in F3 field (becouse current value "n" is greater then "m") and ISAM return "EOF" I think that this simply sequence can be generalized in a standard algorhythm into your SQL engine (... i have already done it in my standard COBOL engine .....) If you want i can send you a complete COBOL source example of the previous example ...... Thank You !! ;-)