Re: Stuck using Sequential Scan

From: Oliver Elphick <olly(at)lfix(dot)co(dot)uk>
To: jeremy(dot)guthrie(at)berbee(dot)com
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Stuck using Sequential Scan
Date: 2004-09-11 06:07:42
Message-ID: 1094882862.14510.982.camel@linda
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, 2004-09-07 at 22:32, Jeremy M. Guthrie wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I have a problem where I have the table format listed below. I have the
> primary key tsyslog_id and the index built against it. However, when I
> select a unique row, it will only ever do a seq scan even after I turn off
> all other types except indexscan. I understand you cannot fully turn off seq
> scan.
...
> I cannot run vacuum more than once a day because of its heavy IO penalty. I
> run analyze once an hour. However, if I run analyze then explain, I see no
> difference in the planners decisions. What am I missing?
>
>
> TSyslog=# \d syslog_tarchive;
> Table "public.syslog_tarchive"
> Column | Type |
> Modifiers
> - ------------+------------------------+-------------------------------------------------------------------------
> tsyslog_id | bigint | not null default
...
>
> TSyslog=# explain select * from tsyslog where tsyslog_id=431650835;

That constant is INTEGER, whereas the column is BIGINT; there is no
automatic conversion in this case, so the planner does not realise the
index is usable for this query (I think 8.0 solves this).

Try: select * from tsyslog where tsyslog_id=431650835::BIGINT;

--
Oliver Elphick olly(at)lfix(dot)co(dot)uk
Isle of Wight http://www.lfix.co.uk/oliver
GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA
========================================
"I am crucified with Christ; nevertheless I live; yet
not I, but Christ liveth in me; and the life which I
now live in the flesh I live by the faith of the Son
of God, who loved me, and gave himself for me."
Galatians 2:20

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Vitaly Belman 2004-09-11 12:45:42 Bad performance with hashjoin
Previous Message Tom Lane 2004-09-10 22:09:57 Re: Interesting performance behaviour