... 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 !!   ;-)



pgsql-sql by date:

Previous
From: "Donald Bauer"
Date:
Subject: subscribe pgsql-sql-digest
Next
From: Wim Kerkhoff
Date:
Subject: bug in translate(text,from,to) ?