I know there have been dozens of threads on this subject and
I have searched the archives well (I hope at least), but still ...
I have
select version();
version
--
PostgreSQL 7.3.4 on hppa-hp-hpux10.20, comp
On 09/02/2004 15:02 Christoph Haller wrote:
[snip]
Thanks for your reply so far, but there is one thing I still don't
understand.
You wrote
It was disabling seqscan that
was forcing an index scan to appear to be the least costly operation.
Why appear? If the Index Scan has a Total runtime: 2.46 mse
Greg Stark <[EMAIL PROTECTED]> writes:
> You could also try lowering random_page_cost. Some people find as low as 1.2
> or so to be useful, but that would almost certainly be lying to postgres about
> the costs of random access and would cause it to use index scans aggressively
> even when they're
Christoph Haller <[EMAIL PROTECTED]> writes:
> Why appear? If the Index Scan has a Total runtime: 2.46 msec and the Seq Scan
> a Total runtime: 46.19 msec, then the Index Scan is much faster.
> Or am I completely off the track reading the explain analyze output?
To estimate the relative costs
>
>
> On 09/02/2004 12:50 Christoph Haller wrote:
>
> >
> > \d Transfer_ModRange
> >Table "public.transfer_modrange"
> > Column | Type | Modifiers
> > +--+---
> > module_pointer | smallint | not null
> > from_module| smallint | not null
> >
On 09/02/2004 12:50 Christoph Haller wrote:
I know there have been dozens of threads on this subject and
I have searched the archives well (I hope at least), but still ...
I have
select version();
version
--
Pos
