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: | Raw Message | Whole Thread | 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 |