Re: Seqscan rather than Index

From: Tom Lane
Subject: Re: Seqscan rather than Index
Date: ,
Msg-id: 21610.1103308612@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: Seqscan rather than Index  (Greg Stark)
List: pgsql-performance

Tree view

Seqscan rather than Index  (Jon Anderson, )
 Re: Seqscan rather than Index  (Tom Lane, )
 Re: Seqscan rather than Index  (David Brown, )
  Re: Seqscan rather than Index  (Richard Huxton, )
   Re: Seqscan rather than Index  (Greg Stark, )
    Re: Seqscan rather than Index  (Tom Lane, )
     Re: Seqscan rather than Index  (Greg Stark, )
      Re: Seqscan rather than Index  (Tom Lane, )
    Re: Seqscan rather than Index  ("Steinar H. Gunderson", )
     Re: Seqscan rather than Index  ("Steinar H. Gunderson", )
      Re: Seqscan rather than Index  (Frank Wiles, )
       Re: Seqscan rather than Index  ("Steinar H. Gunderson", )
       Re: Seqscan rather than Index  (Tom Lane, )
        Re: Seqscan rather than Index  (Frank Wiles, )
     Re: Seqscan rather than Index  (Bruno Wolff III, )
      Re: Seqscan rather than Index  ("Steinar H. Gunderson", )

Greg Stark <> writes:
> Tom Lane <> writes:
>> I think the one effect that's not being modeled is amortization of index
>> fetches across successive queries.

> And across multiple fetches in a single query, such as with a nested loop.

Right, that's effectively the same problem.  You could imagine making a
special-purpose solution for nestloop queries but I think the issue is
more general than that.

> It seems like the effective_cache_size parameter should be having some
> influence here.

But it doesn't :-(.  e_c_s is currently only used to estimate
amortization of repeated heap-page fetches within a single indexscan.

            regards, tom lane


pgsql-performance by date:

From: "Steinar H. Gunderson"
Date:
Subject: Re: Seqscan rather than Index
From: Christopher Browne
Date:
Subject: Re: Which is more efficient?