Re: Why so long?

From: Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>
To: Steve Clark <steve(dot)clark(at)netwolves(dot)com>
Cc: pgsql <pgsql-general(at)postgresql(dot)org>
Subject: Re: Why so long?
Date: 2017-04-20 09:28:18
Message-ID: CAOGQiiMmVCkEAbNQDL9JH10rKbWyNcdMJCndKdHVoULbFNuNxw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Apr 19, 2017 at 8:54 PM, Steve Clark <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?
>
>
> pmacct=# explain select max(id) from netflow;
> QUERY
> PLAN
> ------------------------------------------------------------
> --------------------------------------------------------------
> Result (cost=1.13..1.14 rows=1 width=0)
> InitPlan 1 (returns $0)
> -> Limit (cost=0.71..1.13 rows=1 width=8)
> -> Index Only Scan Backward using netflow_pkey on netflow
> (cost=0.71..3799108784.10 rows=9123246080 width=8)
> Index Cond: (id IS NOT NULL)
> (5 rows)
>
> pmacct=# explain select min(id) from netflow;
> QUERY
> PLAN
> ------------------------------------------------------------
> -----------------------------------------------------
> Result (cost=1.13..1.14 rows=1 width=0)
> InitPlan 1 (returns $0)
> -> Limit (cost=0.71..1.13 rows=1 width=8)
> -> Index Only Scan using netflow_pkey on netflow
> (cost=0.71..3799108784.10 rows=9123246080 width=8)
> Index Cond: (id IS NOT NULL)
> (5 rows)
>
> pmacct=# \timing
> Timing is on.
> pmacct=# select max(id) from netflow;
> max
> -------------
> 17547256873
> (1 row)
>
> Time: 0.626 ms
>
>
>
> pmacct=# select min(id) from netflow;
> ^CCancel request sent
> ERROR: canceling statement due to user request
> Time: 339114.334 ms
>
>
> Table "public.netflow"
> Column | Type
> | Modifiers
> ----------------+-----------------------------+-------------
> --------------------------------------------------------
> id | bigint | not null default
> nextval('netflow_id_seq'::regclass)
> agent_id | bigint |
> bytes | bigint |
> stamp_inserted | timestamp without time zone | not null default
> '0001-01-01 00:00:00'::timestamp without time zone
> stamp_updated | timestamp without time zone |
> packets | integer | default 0
> port_src | integer | default 0
> port_dst | integer | default 0
> ip_proto | smallint | default 0
> tos | smallint | default 0
> ip_src | inet | not null default
> '0.0.0.0'::inet
> ip_dst | inet | not null default
> '0.0.0.0'::inet
> Indexes:
> "netflow_pkey" PRIMARY KEY, btree (id)
> "netflow_ts_key" btree (stamp_inserted)
> "netflow_tsu_idx" btree (stamp_updated)
> Triggers:
> netflow_import AFTER INSERT OR UPDATE ON netflow FOR EACH STATEMENT
> EXECUTE PROCEDURE netflow_update()
>
>
Is this some one-time event or you could reproduce it consistently?

--
Regards,
Rafia Sabih
EnterpriseDB: http://www.enterprisedb.com/

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Rafia Sabih 2017-04-20 09:42:05 Re: Why is this functional index not used?
Previous Message Tim Kane 2017-04-20 07:38:42 Re: UDP buffer drops / statistics collector