the normal queries do not present problems, but all the ones
that join has are very slow.
OBS: I am using way ODBC. He will be that they exist some
configuration specifies inside of the same bank or in the ODBC?
Quoting Rod Taylor <[EMAIL PROTECTED]>:
> On Wed, 2004-02-11 at 09:23, [EMAIL PROTECTED] wrote:
> > my data base is very slow. The machine is a processor Xeon 2GB with
> > 256 MB of RAM DDR. My archive of configuration is this:
>
> I'm not surprised. New values below old.
>
>
> > sort_mem = 131072 # min 64, size in KB
>
> sort_mem = 8192.
>
> > fsync = false
>
> Are you aware of the potential for data corruption during a hardware,
> power or software failure?
>
> > enable_seqscan = false
> > enable_indexscan = false
> > enable_tidscan = false
> > enable_sort = false
> > enable_nestloop = false
> > enable_mergejoin = false
> > enable_hashjoin = false
>
> You want all of these set to true, not false.
>
> > effective_cache_size = 170000 # typically 8KB each
>
> effective_cache_size = 16384.
>
> > random_page_cost = 1000000000 # units are one sequential page fetch cost
>
> random_page_cost = 3
>
> > cpu_tuple_cost = 0.3 # (same)
>
> cpu_tuple_cost = 0.01
>
> > cpu_index_tuple_cost = 0.6 # (same)
>
> cpu_index_tuple_cost = 0.001
>
> > cpu_operator_cost = 0.7 # (same)
>
> cpu_operator_cost = 0.0025
>
> > default_statistics_target = 1 # range 1-1000
>
> default_statistics_target = 10
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
