Index only scans

Поиск
Список
Период
Сортировка
От Shrish Purohit
Тема Index only scans
Дата
Msg-id 14B8F27D7CE40C4C9E481B2B845C2E0D06445FDCDC@EXCHANGE.persistent.co.in
обсуждение исходный текст
Ответы Re: Index only scans  (Sharmila Jothirajah <sjothirajah@regenstrief.org>)
Re: Index only scans  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: functional call named notation clashes with SQL feature
Следующее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: PG 9.0 release timetable