Optimizing AGE()

From: Volkan YAZICI <yazicivo(at)ttmail(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Optimizing AGE()
Date: 2008-06-06 13:20:59
Message-ID: 87abhyaedg.fsf@alamut.mobiliz.com.tr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hi,

Am I wrong or AGE() always gets directed to a sequential scan?

# BEGIN;
] SET enable_seqscan TO off;
] EXPLAIN ANALYZE
] SELECT count(1)
] FROM incomingmessageslog
] WHERE AGE(time) < '1 year';
] ROLLBACK;
BEGIN
SET
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=100000528.33..100000528.34 rows=1 width=0) (actual time=13.789..13.790 rows=1 loops=1)
-> Seq Scan on incomingmessageslog (cost=100000000.00..100000520.00 rows=3333 width=0) (actual time=13.783..13.783 rows=0 loops=1)
Filter: (age((('now'::text)::date)::timestamp without time zone, "time") < '1 year'::interval)
Total runtime: 13.852 ms
(4 rows)

ROLLBACK

As far as I know, AGE() can take advantage of a very simple equation for
constant comparisons:

= AGE(field) < constant_criteria
= AGE(field, constant_ts) < constant_criteria
= AGE(field) < constant_criteria + constant_ts
= AGE(field) < CONSTANT_CRITERIA

How much does such a hack into optimizer cost? I don't know about its
implications but I'll really appreciate such a functionality. At the
moment, I'm trying replace every AGE() usage in my code and it really
feels a PITA.

Regards.

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Mason Sharp 2008-06-06 15:01:27 Re: PgPool parallel query performance rules of thumb
Previous Message Greg Smith 2008-06-06 06:30:23 Checkpoint tuning on 8.2.4