Skip site navigation (1) Skip section navigation (2)

Re: TB-sized databases

From: Bill Moran <wmoran(at)collaborativefusion(dot)com>
To: Csaba Nagy <nagy(at)ecircle-ag(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: TB-sized databases
Date: 2007-11-28 13:54:41
Message-ID: 20071128085441.51705627.wmoran@collaborativefusion.com (view raw or flat)
Thread:
Lists: pgsql-performance
In response to Csaba Nagy <nagy(at)ecircle-ag(dot)com>:

> On Wed, 2007-11-28 at 08:27 -0500, Bill Moran wrote:
> > Is there something wrong with:
> > set enable_seqscan = off
> > ?
> 
> Nothing wrong with enable_seqscan = off except it is all or nothing type
> of thing...

If that's true, then I have a bug report to file:

test=# set enable_seqscan=off;
SET
test=# show enable_seqscan;
 enable_seqscan 
----------------
 off
(1 row)

test=# set enable_seqscan=on;
SET
test=# show enable_seqscan;
 enable_seqscan 
----------------
 on
(1 row)

It looks to me to be session-alterable.

> if you want the big table to never use seqscan, but a medium
> table which is joined in should use it, then what you do ? And setting
> enable_seqscan = off will actually not mean the planner can't use a
> sequential scan for the query if no other alternative exist. In any case
> it doesn't mean "please throw an error if you can't do this without a
> sequential scan".

True.  It would still choose some other plan.

> In fact an even more useful option would be to ask the planner to throw
> error if the expected cost exceeds a certain threshold...

Interesting concept.

-- 
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran(at)collaborativefusion(dot)com
Phone: 412-422-3463x4023

In response to

Responses

pgsql-performance by date

Next:From: Gregory StarkDate: 2007-11-28 13:55:02
Subject: Re: TB-sized databases
Previous:From: Csaba NagyDate: 2007-11-28 13:48:22
Subject: Re: TB-sized databases

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group