| From: | "D(dot) Duccini" <duccini(at)backpack(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | David Olbersen <dave(at)slickness(dot)org>, pgsql-novice(at)postgresql(dot)org |
| Subject: | Re: Indexes not used |
| Date: | 2001-03-16 16:18:45 |
| Message-ID: | Pine.GSO.4.03.10103161014500.5637-100000@ra.bpsi.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-novice |
> If the system needs to fetch more than a small percentage of the
> records, then seqscan *will* be faster. The issue you are dealing
> with seems to be misestimation of the retrieval percentage for this
> particular query, causing the planner to guess wrong about which
> kind of plan to use.
no worries...i'll try building a subset of the data and see if there is
some "threshhold" value
or...maybe its time i actually contributed some code to the project :)
i built an OO database engine a few years ago (in objective-c) that used a
modified N-tree approach to indicies that massively accelerated the
retrieval of a lot of "highly similar" data items
-duck
-----------------------------------------------------------------------------
david(at)backpack(dot)com BackPack Software, Inc. www.backpack.com
+1 651.645.7550 voice "Life is an Adventure.
+1 651.645.9798 fax Don't forget your BackPack!"
-----------------------------------------------------------------------------
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Randy Hall | 2001-03-16 17:11:21 | Re: pg_dump & BLOBs ? |
| Previous Message | Tom Lane | 2001-03-16 16:09:22 | Re: Indexes not used |