Kynn Jones wrote:
my_db=> SET ENABLE_SEQSCAN TO OFF;
my_db=> EXPLAIN ANALYZE SELECT * FROM T NATURAL JOIN B;
QUERY PLAN
---
"Kynn Jones" <[EMAIL PROTECTED]> writes:
> So it seems like turning off ENABLE_SEQSCAN is the way to go.
Try reducing random_page_cost a bit instead. Also, have you got
effective_cache_size set to something that's realistic for your
machine?
One problem with this test is that your smaller tables
On Sat, Mar 8, 2008 at 1:01 PM, Heikki Linnakangas <[EMAIL PROTECTED]>
wrote:
> Kynn Jones wrote:
> > Hi!
> >
> > As part of a data warehousing project, I need to pre-process data
> downloaded
> > from an external source, in the form of several large flat files. This
> > preprocessing entails che
Kynn Jones wrote:
Hi!
As part of a data warehousing project, I need to pre-process data downloaded
from an external source, in the form of several large flat files. This
preprocessing entails checking the validity of various data items, and
discarding those that fail to pass all the checks.
Cu
Hi!
As part of a data warehousing project, I need to pre-process data downloaded
from an external source, in the form of several large flat files. This
preprocessing entails checking the validity of various data items, and
discarding those that fail to pass all the checks.
Currently, the code th
petchimuthu lingam escribió:
> VQQ7HE18
Please stop sending this nonsense. These "sending confirmations" are
not necessary -- they are sent by a clueless user whose identity we've
as of yet unable to determine (otherwise we would have kicked him from
the list.)
--
Alvaro Herrera
On 6-3-2008 16:28 Craig James wrote:
On the one hand, I understand that Postgres has its architecture, and I
understand the issue of row visibility, and so forth. On the other
hand, my database is just sitting there, nothing going on, no
connections except me, and... it takes FIFTY FIVE SECOND
