Willy-Bas Loos wrote:
>Hi,
>
>I'm using PostgreSQL 8.4 (and also 8.3).
>
>A partial index like this:
>CREATE INDEX table2_field1_idx
> ON table2 (field1)
> WHERE NOT field1 ISNULL;
>
>Will not be used when select one record from 100K records:
>
>explain select * from table2 where field1 = 2569
I have to say I've been really impressed with the quality and diversity
of tools here to increase performance for PostgreSQL. But I keep seeing
a lot of the same basic things repeated again and again. Has anyone
looked into a "smart" or auto-adjusting resource manager for postgres?
Conside
Hello All,
I've inherited a postgresql database that I would like to refactor. It
was origionally designed for Postgres 7.0 on a PIII 500Mhz and some
design decisions were made that don't make sense any more. Here's the
problem:
1) The database is very large, the largest table has 40 mil
We are running Postgres 8.0.2 with the 8.0.2 jdbc
driver. And yes we are using prepared statements.
I've spent hours trying to get the
'log_min_duration_statement' and 'log_duration'
options to work with no luck. I never get any
duration from the statement. I also never see 'begin'
or 'commit'
ent
> to the duration using
> the process ID or session ID. The default is off.
> Only superusers can
> change this setting.
>
> Brent Henry wrote:
> > Help! After recently migrating to Postgres 8,
> I've
> > discovered to my horror that I can't determine
> wh
Help! After recently migrating to Postgres 8, I've
discovered to my horror that I can't determine which
queries are poorly performing anymore because the
logging has drastically changed and no longer shows
durations for anything done through JDBC.
So I'm desperately trying to do performance tunin
I'll see where I can make my
script itself go faster, but I don't think I'll be able to do much.
I'll do some pre-prepare type stuff, but I don't expect significant
gains, maybe 5-10%. I'd could happily turn off fsync for this job, but
not for some other databases
On Wed, 2004-02-04 at 21:27, Josh Berkus wrote:
Orion,
> I've done some testing of 7.3.4 vs 7.4.1 and found 7.4.1 to be 20%-30%
> slower than 7.3.4. Is this common knowledge or am I just unlucky with
> my query/data selection?
No, it's not common knowledge. It should be the other way aroun
On Fri, 2004-02-06 at 02:44, Hannu Krosing wrote:
> Christopher Browne kirjutas N, 05.02.2004 kell 07:32:
> > Oops! [EMAIL PROTECTED] (Orion Henry) was seen spray-painting on a wall:
> > > Oh... as a side note I'm happy to announce that the 2.6 Linux kernel
> > > ha
On Fri, 2004-02-06 at 02:43, Hannu Krosing wrote:
> Orion Henry kirjutas N, 05.02.2004 kell 07:16:
> > I've done some testing of 7.3.4 vs 7.4.1 and found 7.4.1 to be 20%-30%
> > slower than 7.3.4. Is this common knowledge or am I just unlucky with
> > my query/data sel
>
> One question though... It sounds like your 7.3 binaries are 64-bit and
> your 7.4 binaries are 32-bit. Have you tried grabbing the SRPM for 7.4
> and recompiling it for X86_64?
No, they were all 64 bit.
I'm going to run explains on all my queries and see if I can find
anything of interes
--
Orion Henry <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
Quick Question,
The full query listed in pg_stat_activity is getting truncated. Does
anyone know how I can see the full query in progress?
--
Orion Henry <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
Thanks Tom! You're a life-saver.
On Fri, 2004-01-23 at 17:08, Tom Lane wrote:
> Orion Henry <[EMAIL PROTECTED]> writes:
> > The queries usually are in the form of, where "user_id = something and
> > event_time between something and something".
>
> >
Also, would it make sense for me to raise my ANALYZE value and how would
I go about doing this?
Thanks for the help.
--
Orion Henry <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
15 matches
Mail list logo
