Horton

Re: So, is COUNT(*) fast now?

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: pgsql-hackers@postgresql.org
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>
Date: 2011-10-22T15:54:14Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Remove pg_upgrade dependency on the 'postgres' database existing in the

On Saturday, October 22, 2011 05:20:26 PM Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On Friday, October 21, 2011 08:14:12 PM Robert Haas wrote:
> >> On Fri, Oct 21, 2011 at 2:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >>> It's not "touching six times less data".  It's touching the exact same
> >>> number of tuples either way, just index tuples in one case and heap
> >>> tuples in the other.
> >> 
> >> Yeah, but it works out to fewer pages.
> > 
> > But access to those is not sequential. I guess if you measure cache hit
> > ratios the index scan will come out significantly worse.
> 
> Huh?  In the case he's complaining about, the index is all in RAM.
> Sequentiality of access is not an issue (at least not at the page
> level --- within a page I suppose there could be cache-line effects).
I was talking about L2/L3 caches...

Andres