| From: | Pierre-Frédéric Caillaud <lists(at)boutiquenumerique(dot)com> | 
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org | 
| Subject: | Re: LIMIT causes SEQSCAN in subselect | 
| Date: | 2004-12-24 01:47:40 | 
| Message-ID: | opsjholqqlcq72hf@musicbox | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-performance | 
> The fact that the estimator knows that the LIMIT is pointless because  
> there
> are less rows in the subselect than the LIMIT will return is not  
> something we
> want to count on; sometimes the estimator has innaccurate information.   
> The
> UNIQUE index makes this more certain, except that I'm not sure that the
> planner distinguishes between actual UNIQUE indexes and columns which are
> estimated unique (per the pg_stats).   And I think you can see in your  
> case
> that there's quite a difference between a column we're CERTAIN is unique,
> versus a column we THINK is unique.
	I think a UNIQUE constraint can permit several 'different' NULL values...  
better say "UNIQUE NOT NULL" ?
	
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pierre-Frédéric Caillaud | 2004-12-24 02:05:59 | Re: Using LIMIT changes index used by planner | 
| Previous Message | Tom Lane | 2004-12-23 22:44:34 | Re: Memory leak tsearch2 VACUUM FULL VERBOSE ANALYZE |