Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Janes <jeff.janes@gmail.com>, pgsql-hackers@postgresql.org
Date: 2011-10-22T21:15:20Z
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

Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Oct 21, 2011 at 10:57 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
>> If count(*) could cause the index-only scan to happen in physical
>> order of the index, rather than logical order, that might be a big
>> win. Both for all in memory and for not-all-in-memory.

> That's an interesting point.  I sort of assumed that would only help
> for not-all-in-memory, but maybe not.  The trouble is that I think
> there are some problematic concurrency issues there.

Yeah.  We managed to make physical-order scanning work for VACUUM
because it's okay if VACUUM sometimes sees the same index tuple twice;
it'll just make the same decision about (not) deleting it.  That will
not fly for regular querying.

			regards, tom lane