... A LITTLE IDEA TO OPTIMIZE SELECT STATEMENT

From: Nicola Cisternino <ncister(at)tin(dot)it>
To: pgsql-sql(at)postgresql(dot)org
Subject: ... A LITTLE IDEA TO OPTIMIZE SELECT STATEMENT
Date: 2000-02-14 16:06:20
Message-ID: 38A827FB.1E048911@tin.it
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 !! ;-)

Browse pgsql-sql by date

  From Date Subject
Next Message Wim Kerkhoff 2000-02-14 18:23:58 bug in translate(text,from,to) ?
Previous Message Donald Bauer 2000-02-13 21:36:45 subscribe pgsql-sql-digest