| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Josh Berkus <josh(at)agliodbs(dot)com> |
| Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ants Aasma <ants(at)cybertec(dot)at>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Why is indexonlyscan so darned slow? |
| Date: | 2012-05-21 21:07:13 |
| Message-ID: | CA+U5nM+HC9LnaX2Lch5BhybqscwAe2cQiSFd-iO+ynRrE9=g7A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 21 May 2012 16:42, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
>> Earlier you said that this should be an ideal setup for IOS. But it
>> isn't really--the ideal set up is one in which the alternative to an
>> IOS is a regular index scan which makes many uncached scattered reads
>> into the heap. I don't think that that situation can't really be
>> engineered with a where-less query.
>
> Can you give me some suggested comparisons which *would* be ideal, then?
Presumably the use case we were tuning for was established prior to
development of the patch?
Surely the performance test results that demonstrate the gain have
been posted to hackers, so we just need to refer back to them?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2012-05-21 21:17:26 | Re: Why is indexonlyscan so darned slow? |
| Previous Message | Heikki Linnakangas | 2012-05-21 20:56:17 | Re: Bug in new buffering GiST build code |