Re: Index only scans - Mailing list pgsql-hackers
From | Sharmila Jothirajah |
---|---|
Subject | Re: Index only scans |
Date | |
Msg-id | 673107EFBDBE53419C100C0A56E118CA0EF2372532@rg-exchange.RII.local Whole thread Raw |
In response to | Index only scans (Shrish Purohit <shrish_purohit@persistent.co.in>) |
List | pgsql-hackers |
Hi Shrish, I saw the excel that you sent to Heikki. Here are my comments. 1. Don't worry about comparing the results with Oracle. Just take pg-normal and pg-enhanced. That's what the community caresabout. Later we can also add Oracle's performance. 2. In the excel sheet you have 'simple queries' and 'simple queries repeated'...you have to compile them together. 3. Also for pg-normal, the queries are run with seq scan and not forcing 'index scan' . If you compare that run with pg-enhancedit will definitely look bad. You have to compare pg-enh with pg-normal's indexscan (and also seq scan). That willgive a complete picture. These performance numbers that we sent them is very important. Make sure the excel is formatted and is very clear beforeyour sent the numbers. Its hard to get the community to respond if our reports are not clear Thanks Sharmila -----Original Message----- From: Shrish Purohit [mailto:shrish_purohit@persistent.co.in] Sent: Monday, May 31, 2010 11:09 AM To: Heikki Linnakangas Cc: pgsql-hackers@postgresql.org; Sharmila Jothirajah; Mahesh Nalkande; Arvind Hulgeri; Sameer Pendharkar Subject: Index only scans Hi Heikki, Pgsql-Hackers, Sometime back you have started with "Separate Heap Fetch from Index Scan" which was planned to support partial index onlyscans. Are you still working on it or do you know someone still working on it? We did some development with Gokul's Index Only Patch and have got good performance numbers which are as follows: Test table constitutes 0.5 billion records with thick index on (id,aid) on three machines {pg_normal , pg_enhanced( PGSQLwith thick index feature ), Oracle} each having 16 Gb Ram. Disk I/O obtained using sar. testdb=# \d test Table "public.test" Column | Type | Modifiers -----------+------------------+-----------id | integer |startdate | date |enddate | date |charge | double precision |firstname | text |lastname | text |aid | double precision|bid | double precision | Indexes: "taid" THICK btree (id, aid) CLUSTER Index size On oracle 15.20 Gb On Pg-normal 14.73 Gb Pg_enhanced 23.17 Gb (16bytes*0.5billion = ~7.6 GB) PFA excel sheet for details. In general we saw fair amount of performance improvement, but one thing that surprises us isthat after around 20% tuples updated we found oracle taking more time. Regards, Shrish Purohit |Senior Software Engineer|Persistent Systems shrish_purohit@persistent.co.in |Cell:+91-9850-959-940|Tel:+91(20)302-34493 Innovation in software product design, development and delivery- www.persistentsys.com DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intendedonly for the use of the individual or entity to which it is addressed. If you are not the intended recipient, youare not authorized to read, retain, copy, print, distribute or use this message. If you have received this communicationin error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not acceptany liability for virus infected mails.
pgsql-hackers by date: