On 30/03/2011 19:49, Etienne Robillard wrote:
On 30/03/11 12:56 PM, julia.jacob...@arcor.de wrote:
Hello Etienne,
Thanks for your answer.
What do you mean by "you may have hitten yourself in the foot with the
--disable-shared option"?
When I don't use this option, everything works fine.
Compil
Thank you for all your suggestions - will attempt to make changes as
recommended one at a time and will post back the results.
Regards,
Lawrence Cohan.
-Original Message-
From: pgsql-bugs-ow...@postgresql.org [mailto:pgsql-bugs-ow...@postgresql.org]
On Behalf Of Kevin Grittner
Sent: Mar
Lawrence Cohan wrote:
> looks like we will need to change at least the two values below
> and maybe play with work_mem to see if it solves our issues.
You will probably get better throughput by bumping up
shared_buffers to the recommended setting, but beware of "stalls" in
query processing at
Harry Rossignol wrote:
> I'm just a lowly end user. Bumping the default statistics target
> or using ALTER TABLE SET STATISTICS has made large differences in
> query performance on large tables.
The default has been bumped up in later versions, so that shouldn't
be as big a problem as it once
I'm just a lowly end user. Bumping the default statistics target or
using ALTER TABLE SET STATISTICS has made large differences in query
performance on large tables.
The query planner has to guesstimate using the statistics. Sometimes on
large tables the guesstimate isn't very good with a small
I think you are right (my bad) and please see the results below plus a little
bit more info about the environment and sorry I missed that before. I've been
told the server was tuned to the best for what we need and looks like we will
need to change at least the two values below and maybe play wi
Lawrence Cohan wrote:
> Please see updated attachment that includes the tables involved in
> the simple query below and all their indexes.
Well, that rules out a couple common problems (comparisons between
different types and incorrect indexing).
> We believe that the performance issue is du
Please see updated attachment that includes the tables involved in the simple
query below and all their indexes. We believe that the performance issue is due
to the query not using any index but doing seq scans instead and this is very
little related to the knowledge from the link you posted bel
Please bear with me, as it's taken me a while to be able to reproduce an
issue that is worrisome.
Before I describe the problem, I am using postgresql version 8.4.5 on
CentOS 5.5 (x86_64).
The short version is that if a postgresql backend is killed (by the Linux
OOM handler, or kill -9, etc...) w
Lawrence Cohan wrote:
> From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
>> [configuration advice]
>> If, after reading the above-cited page and tuning your server you
>> still have performance problems, pick one query to work on first,
>> and follow the step outlined here:
>>
>> htt
Hello Etienne,
Thanks for your answer.
What do you mean by "you may have hitten yourself in the foot with the
--disable-shared option"?
When I don't use this option, everything works fine.
Compiling PostgreSQL 8.4.7 doesn't work either.
The problem is that I need a static libpq. Leaving out the
We thank you for the links that have a lots of info and please note that we
tuned our servers as recommended by Enterprise DB experts while they were in
house for our hardware/software migrations and the setting you mentioned are in
place already.
Regards,
Lawrence Cohan.
-Original Message
Please see results attached before and after the vacuum and note they are taken
from version 9.0
As regular maintenance we reindex/vacuum/analyze entire database once a week
and run ANALYZE against it every few hours.
Lawrence Cohan.
-Original Message-
From: Pavel Stehule [mailto:pavel
Lawrence Cohan wrote:
> We have a huge performance issues in Postgres that surfaced due to
> existing indexes not being used
This doesn't sound like a bug; it sounds like you haven't tuned your
server.
For starters, you should check out this page:
http://wiki.postgresql.org/wiki/Tuning_You
Thanks for the tip however No 1 is that we can't do that in the production
environment due to impact and No 2 that I tried that and is still not using an
index on the large table but seq scan.
From: Nathan M. Davalos [mailto:n.dava...@sharedmarketing.com]
Sent: March-30-11 12:05 PM
To: Lawrence
Hello
2011/3/30 Lawrence Cohan :
> We have a huge performance issues in Postgres that surfaced due to existing
> indexes not being used like in the example below in both 8.35 and 9.0
> versions.
>
>
>
> Client_Orders table with and int ID as PK which is the order_id and indexed
> – about 155,000 r
I force postgresql to use indexes instead of sequential scans by setting
enable_seqscan = off in postgresql.conf and it helps in a lot of cases.
Probably not the best practice, but it does improve a lot of the queries
we will execute on a regular basis. It forces the planner to prefer
indexes. I've
We have a huge performance issues in Postgres that surfaced due to existing
indexes not being used like in the example below in both 8.35 and 9.0 versions.
Client_Orders table with and int ID as PK which is the order_id and indexed -
about 155,000 rows
Order_Items table with and int ID primary k
On 30/03/11 09:54 AM, Julia Jacobson wrote:
> The following bug has been logged online:
>
> Bug reference: 5960
> Logged by: Julia Jacobson
> Email address: julia.jacob...@arcor.de
> PostgreSQL version: 8.4.6
> Operating system: Windows 7 with Msys/MinGW
> Description:N
Hi,
As Mohammed Rashad wrote in the past I have still the same problems with
Linux Mint Version 10.
I install it via the package manager "synaptic" and during the installation
I got an error message,
analogous "can not start postgres because postgresql 8.4 is not configured"
So for me it looks
Additional: if i start postgresql with user postgres then I got the the
following message:
postgres@delta ~ $ /usr/lib/postgresql/8.4/bin/pg_ctl start
/usr/lib/postgresql/8.4/bin/pg_ctl: symbol lookup error:
/usr/lib/postgresql/8.4/bin/pg_ctl: undefined symbol:
PQconnectionNeedsPassword
Is there
The following bug has been logged online:
Bug reference: 5960
Logged by: Julia Jacobson
Email address: julia.jacob...@arcor.de
PostgreSQL version: 8.4.6
Operating system: Windows 7 with Msys/MinGW
Description:No rule to make target 'libpq.a', needed by
'all-static-lib
The following bug has been logged online:
Bug reference: 5959
Logged by: Per-Olov Esgard
Email address: per-olov.esg...@micronic-mydata.com
PostgreSQL version: 9.0.0
Operating system: Linux / kernel 2.6.16.20
Description:pg_restore --use-list does not always work wit
On Fri, Mar 25, 2011 at 08:26:09AM +, shenwenguang wrote:
> PHP5 + PostgreSQL8.4 + ubuntu 11.04
>
> 1: insert any items , about 1000 rows
> 2: delete any items, about 100 rows
> 3: repeat 1,2;
>
> When restart server,
> that Error disappear,
> repeat some deleted,insert operation,
> mistak
24 matches
Mail list logo
