2010/3/25 Robert Haas :
> On Wed, Mar 17, 2010 at 9:01 PM, Eger, Patrick wrote:
>> I'm running 8.4.2 and have noticed a similar heavy preference for
>> sequential scans and hash joins over index scans and nested loops. Our
>> database is can basically fit in cache 100% so this may not be
>> appli
On Wed, Mar 24, 2010 at 8:59 PM, Eger, Patrick wrote:
> Ok, the wording is a bit unclear in the documentation as to whether it is the
> cost for an entire *page* of tuples, or actual tuples. So something like the
> following might give better results for a fully-cached DB?
>
> seq_page_cost = 1.
Cc: Christian Brink; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Forcing index scan on query produces 16x faster
On Wed, Mar 17, 2010 at 9:01 PM, Eger, Patrick wrote:
> I'm running 8.4.2 and have noticed a similar heavy preference for
> sequential scans and hash joins over
On Wed, Mar 17, 2010 at 9:01 PM, Eger, Patrick wrote:
> I'm running 8.4.2 and have noticed a similar heavy preference for
> sequential scans and hash joins over index scans and nested loops. Our
> database is can basically fit in cache 100% so this may not be
> applicable to your situation, but t
I've also observed the same behaviour on a very large table (200GB data,
170GB for 2 indexes)
I have a table which has 6 small columns, let's call them (a, b, c, d, e, f)
and about 1 billion rows. There is an index on (a, b, c, d) - not my idea,
Hibernate requires primary keys for every table
I'm running 8.4.2 and have noticed a similar heavy preference for
sequential scans and hash joins over index scans and nested loops. Our
database is can basically fit in cache 100% so this may not be
applicable to your situation, but the following params seemed to help
us:
seq_page_cost = 1.0
ran
Christian Brink writes:
> Is there a way to rewrite or hint the planner to get me the better plan
> without resorting to 'enable_seqscan' manipulation (or am I missing
> something)?
I think your problem is here:
> PostgreSQL 8.0.3 on i386-redhat-linux-gnu, compiled by GCC
> i386-redhat-linu
On Wed, Mar 17, 2010 at 5:25 PM, Christian Brink wrote:
>
> -> Index Scan using sales_tranzdate_index on sales s
> (cost=0.01..1825.27 rows=22530 width=12) (actual time=0.072..3.464 rows=225
> loops=1)
>
Have you tried increasing the statistics on that table (and then analyzing)?
