Re: Why so long?

From: Steve Clark <steve(dot)clark(at)netwolves(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: pgsql <pgsql-general(at)postgresql(dot)org>
Subject: Re: Why so long?
Date: 2017-04-19 16:20:16
Message-ID: 1016f7cc-3acf-b6ab-d1d4-cd29df85fe7b@netwolves.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 04/19/2017 11:57 AM, Jeff Janes wrote:
> On Wed, Apr 19, 2017 at 8:24 AM, Steve Clark <steve(dot)clark(at)netwolves(dot)com <mailto:steve(dot)clark(at)netwolves(dot)com>> wrote:
>
> Hello,
>
> I am confused. I have a table that has an incrementing primary key id.
>
> When I select max(id) from table is returns almost instantly but
> when I select min(id) from table it takes longer than I want to wait.
>
> Shouldn't postgresql be able to quickly find the minimum id value in the index?
>
>
> Not if the low end of the index is stuffed full of obsolete entries, which haven't been cleaned up because it is not being vacuumed often enough.
>
> Do you have autovacuum on? Have you manually vacuumed the table recently?
>
> Cheers,
>
> Jeff
Hi Jeff,

Autovacuum is turned on.

schemaname | relname | last_vacuum | last_autovacuum | vacuum_count | autovacuum_count
------------+-----------------------+-------------+-------------------------------+--------------+------------------
public | netflow | | 2017-04-11 01:18:53.261221-04 | 0 | 1

It is a large table.
select pg_size_pretty(pg_relation_size('netflow'));
pg_size_pretty
----------------
1267 GB

select pg_size_pretty(pg_total_relation_size('netflow_pkey'));
pg_size_pretty
----------------
287 GB

Regards,
Steve

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Alexandre 2017-04-19 16:24:32 Re: Recover corrupted data
Previous Message Moreno Andreo 2017-04-19 16:11:28 Re: Recover corrupted data