Re: the big picture for index-only scans

On Wed, May 11, 2011 at 1:47 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Greg Stark wrote:
>> On a separate note though, Simon, I don't know what you mean by "we
>> normally start with a problem". It's an free software project and
>> people are free to work on whatever interests them whether that's
>> because it solves a problem they have, helps a client who's paying
>> them, or just because it's of academic interest to them. We don't
>> always take their patches if they aren't of general interest but
>> people propose all kinds of crazy experimental ideas all the time.
>
> I am confused by Simon's questions too.
>
> Simon seems to regularly argue for adding features late in the
> development cycle and backpatch things no one else thinks should be
> backpatched, but he wants more research that index-only scans are going
> to improve things before it is implemented?   The first is aggressive
> development, the second is very conservative development --- they don't
> match, so I now wonder what the motivation is since it isn't consistent.

Not really sure why reasonable technical skepticism should become
personal commentary.

You don't question Tom's motives if he is skeptical of an idea of
mine. Why would you question my motivation? What is *your* motive for
acting like that?

I'm not driven by one setting of "conservatism", but I am interested
in adding fully usable features that bring credit to the project. If I
see a feature that can have minor things added to it to improve them,
then I raise that during beta. If I see things being worked out that
sounds dubious, I mention that in early development.

I don't think this work will materially improve the speed of count(*)
in majority of cases. This introduces extra overhead into the code
path and that can be a net loss. The only time it will help is when
you have a large table that is not cached and also not recently
updated. Is count(*) run very often against such tables? Do we really
care enough to optimise that use case with lots of special purpose
code? The very fact that Kevin and yourself bring up different reasons
for why we need this feature makes me nervous.

The analysis has not been done yet, and all I have done is request that.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services