A furthur thought or two:
- you are *sure* that it is Postgres that is slow? (could be Php...or your
machine could be out of some resource - see next 2 points)
- is your machine running out of cpu or memory?
- is your machine seeing huge io transfers or long io waits?
- are you running Php on th
Quoting Stephane Tessier <[EMAIL PROTECTED]>:
General parameter suggestions:
> shared_buffers = 128000 # min max_connections*2 or 16, 8KB each
> effective_cache_size = 196608 # typically 8KB each
Try reducing shared_buffers (say 3). There has been much discussion regards
setting t
On Thu, 29 Jul 2004 03:08 am, Stephane Tessier wrote:
> Hi everyone,
>
> somebody can help me??? my boss want to migrate to
> ORACLE
>
> we have a BIG problem of performance,it's slow
> we use postgres 7.3 for php security application with approximately 4
> millions of inser
can anyone imagine why my query refuses to use indexes for a
foo.val<=bar.val query (but works for foo.val=bar.val foo.val<=1). the
i_value fields are ints (int4), and selectivity of both of these queries
is 2/1. and I'm running pgsql 7.4.3.
Also, the default_statistics_target is 1000 and I
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > I would much rather see postgres 'get' (a,b,c) > (a1,
> > b1, c1)...if there is even a chance this is possible, I'll direct my
> > efforts there.
>
> For the ISAM context this whole discussion is kinda moot, because you
> really don't want to have
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> However, this would work:
> Create index on t(stackparam(array[a::text,b::text,c::text),
> array['char(2)', 'int', 'date')];
Well, I fear not all datatypes sort properly when treated as text. Notably
integers don't. "10" sorts before "2" for example
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> I would much rather see postgres 'get' (a,b,c) > (a1,
> b1, c1)...if there is even a chance this is possible, I'll direct my
> efforts there.
For the ISAM context this whole discussion is kinda moot, because you
really don't want to have to plan and e
Greg Stark wrote:
> Well I'm not sure whether you caught it, but Tom did come up with a
> work-around that works with the current infrastructure if all the
columns
> involved are the same datatype.
>
> You can create a regular btree index on the expression array[a,b,c]
and
> then
> do your lookup
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Well, if and when the rowtype comparison can be made to work over multi
> part keys (and the optimizer is made to do tricks there), postgres can
> be made to give much better generalized ISAM access. In the meantime,
> I'll just troubleshoot specifi
Stan Bielski <[EMAIL PROTECTED]> writes:
> I having a great deal of difficulty getting postgres to do a hash join.
> Even if I disable nestloop and mergejoin in postgres.conf, the optimizer
> still refuses to select hash join.
Are you sure the join condition is hashjoinable? You didn't say
anythi
Just an update on this:
queries in the 'next key' form on fields(a,b,c)
only ever use the index for the first field (a). I just never noticed
that before...in most cases this is selective enough. In most logical
cases in multi part keys the most important stuff comes first.
Curiously, queries in
On Tue, 27 Jul 2004, Stan Bielski wrote:
> I having a great deal of difficulty getting postgres to do a hash join.
> Even if I disable nestloop and mergejoin in postgres.conf, the optimizer
> still refuses to select hash join. This behavior is killing my
> performance.
>
> Postgres version is 7.3.
I have the following query that I have to quit after 10 mins. I have vacuum full
analyzed each of the tables and still nothing seems to help. There are indexes on all
the join fields. I've included the query, explain and the table structures. Please
let me know if there is anything else I sh
Hi
everyone,
somebody can help
me??? my boss want to migrate to ORACLE
we have a BIG
problem of performance,it's slow
we use postgres 7.3
for php security application with approximately 4 millions of insertion by
day and 4 millions of delete and update
and archiv
Hello,
I having a great deal of difficulty getting postgres to do a hash join.
Even if I disable nestloop and mergejoin in postgres.conf, the optimizer
still refuses to select hash join. This behavior is killing my
performance.
Postgres version is 7.3.2 and relevant tables are vacuum analyzed.
H
15 matches
Mail list logo
