pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Matt Daw <matt@shotgunsoftware.com>
To: pgsql-performance@postgresql.org
Subject: Re: Performance of Seq Scan from buffer cache
Date: Tue, 21 Aug 2012 16:59:51 -0700
Message-ID: <5673F06B4FCF43B281B25DC9BB758298@shotgunsoftware.com> (raw)
In-Reply-To: <5B826B9835204EFD8E3A3DD6D14A0235@shotgunsoftware.com>
References: <5B826B9835204EFD8E3A3DD6D14A0235@shotgunsoftware.com>

Ugh, never mind. I ran ltrace and it's spending 99% of its time in gettimeofday.  

select count(*) from notes;
  count   
---------
 1926207
(1 row)

Time: 213.950 ms

explain analyze select count(*) from notes;
                                                       QUERY PLAN                                                        
------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=99274.59..99274.60 rows=1 width=0) (actual time=2889.325..2889.325 rows=1 loops=1)
   ->  Seq Scan on notes  (cost=0.00..94459.07 rows=1926207 width=0) (actual time=0.005..1475.218 rows=1926207 loops=1)
 Total runtime: 2889.360 ms
(3 rows)

Time: 2889.842 ms  


On Tuesday, 21 August, 2012 at 3:57 PM, Matt Daw wrote:

> Howdy. I'm curious what besides raw hardware speed determines the performance of a Seq Scan that comes entirely out of shared buffers… I ran the following on the client's server I'm profiling, which is otherwise idle:
>  
> EXPLAIN (ANALYZE ON, BUFFERS ON) SELECT * FROM notes;
>  
> Seq Scan on notes  (cost=0.00..94004.88 rows=1926188 width=862) (actual time=0.009..1673.702 rows=1926207 loops=1)
>    Buffers: shared hit=74743
>  Total runtime: 3110.442 ms
> (3 rows)
>  
>  
> … and that's about 9x slower than what I get on my laptop with the same data. I ran stream-scaling on the machine and the results seem reasonable (8644.1985 MB/s with 1 core -> 25017 MB/s with 12 cores). The box is running 2.6.26.6-49 and postgresql 9.0.6.
>  
> I'm stumped as to why it's so much slower, any ideas on what might explain it… or other benchmarks I could run to try to narrow down the cause?
>  
> Thanks!
>  
> Matt  

view thread (3+ messages)  latest in thread

Message-ID: <5673F06B4FCF43B281B25DC9BB758298@shotgunsoftware.com>
Permalink:  ../5673F06B4FCF43B281B25DC9BB758298@shotgunsoftware.com/
Also on:    postgresql.org/message-id/5673F06B4FCF43B281B25DC9BB758298@shotgunsoftware.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: matt@shotgunsoftware.com
  Subject: Re: Performance of Seq Scan from buffer cache
  In-Reply-To: <5673F06B4FCF43B281B25DC9BB758298@shotgunsoftware.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox