Re: SELECT * FROM LIMIT 1; is really slow - Mailing list pgsql-hackers
From Paul Ramsey
Subject Re: SELECT * FROM LIMIT 1; is really slow
Date
Msg-id 40B566A3.2090808@refractions.net
Whole thread Raw
In response to Re: SELECT * FROM LIMIT 1; is really slow  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:

> of dead tuples followed by a lot of pages worth of live tuples.  Plain
> VACUUM cannot do much to fix this since it doesn't move rows around.
> VACUUM FULL will fix it, but its index-update overhead is high enough
> that CLUSTER is a better deal.

Tom: I was interested in performance improvements from cluster, so I 
tried to cluster a table on a spatial index:

dra_working=# \d geomtest        Table "public.geomtest"     Column     |   Type   | Modifiers
----------------+----------+----------- rd_segment_id  | integer  | admit_date     | date     | retire_date    | date
 | most_recent    | boolean  | lineargeometry | geometry |
 
Indexes: geomtest_idx gist (lineargeometry)

dra_working=# cluster geomtest_idx on geomtest;
ERROR:  CLUSTER: cannot cluster when index access method does not handle 
nulls
You may be able to work around this by marking column "lineargeometry" 
NOT NULL
dra_working=# select version();              version
--------------------------------------- PostgreSQL 7.3.6 on i686-pc-linux-gnu


As of quite a while ago (7.2?) the GiST access method was made null-safe 
by Teodor and Oleg, I think. Is this a safety wrapper left over from 
before the upgrade to GiST?


--       __     /     | Paul Ramsey     | Refractions Research     | Email: pramsey@refractions.net     | Phone: (250)
885-0632    \_
 


pgsql-hackers by date:

Previous
From: James Robinson
Date:
Subject: Re: tablespaces and DB administration
Next
From: Alvaro Herrera
Date:
Subject: Re: Nested xacts: looking for testers and review