Skip site navigation (1) Skip section navigation (2)

Re: Good News re count(*) in 8.1

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Greg Stark" <gsstark(at)mit(dot)edu>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Good News re count(*) in 8.1
Date: 2006-02-23 18:54:52
Message-ID: 43FDB09C.EE98.0025.0@wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-performance
>>> On Wed, Feb 22, 2006 at  9:52 pm, in message
<87irr6zq7j(dot)fsf(at)stark(dot)xeocode(dot)com>, Greg Stark <gsstark(at)mit(dot)edu> wrote:


> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> 
>> There have been several times that I have run a SELECT COUNT(*) on
an entire
>> table on all central machines. On identical hardware, with identical
data,
>> and equivalent query loads, the PostgreSQL databases have responded
with a
>> count in 50% to 70% of the time of the commercial product, in spite
of the
>> fact that the commercial product does a scan of a non- clustered
index while
>> PostgreSQL scans the data pages.
> 
> I take it these are fairly narrow rows? The big benefit of index-
only scans
> come in when you're scanning extremely wide tables, often counting
rows
> matching some indexed criteria.

I'm not sure what you would consider "fairly narrow rows" -- so see the
attached.  This is the VACUUM ANALYZE VERBOSE output for the largest
table, from last night's regular maintenance run.

-Kevin



Attachment: CaseHist-vacuum-analyze.txt
Description: application/octet-stream (1.5 KB)

In response to

Responses

pgsql-performance by date

Next:From: Tomeh, HusamDate: 2006-02-23 19:57:03
Subject: Re: 0ut of Memory Error during Vacuum Analyze and
Previous:From: Tom LaneDate: 2006-02-23 17:25:22
Subject: Re: Slow query

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group