-bugs@postgresql.org; Lawrence Cohan
Subject: Re: [BUGS] Postgres not using indexes
Lawrence Cohan lco...@web.com 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
Lawrence Cohan lco...@web.com wrote:
We managed to put together a new test server running PG 9.0.2 on
2socketsx6cores = 12CPU with 64 GB RAM against a 3PAR 10TB SAN. We
kept the settings I submitted already (and enclosed below) and
after 12 hours of pounding the box with PGBENCH running 8
Cohan
Subject: RE: [BUGS] Postgres not using indexes
Lawrence Cohan lco...@web.com wrote:
We managed to put together a new test server running PG 9.0.2 on
2socketsx6cores = 12CPU with 64 GB RAM against a 3PAR 10TB SAN. We
kept the settings I submitted already (and enclosed below) and
after 12
Greg Stark gsst...@mit.edu wrote:
On Thu, Mar 31, 2011 at 11:33 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Greg Stark gsst...@mit.edu wrote:
your query does require reading all the data.
Huh? It requires reading all the data from at least *one* of the
tables.
The query he
Thank you for all your suggestions and I hope the set enable_seqscan = off;
will work for the time being until we can make PG config changes and more
testing in the near future. We expect indeed much better performance with index
being used on the 33+million rows table vs seq scan and I will
On Wed, Mar 30, 2011 at 7:32 PM, Lawrence Cohan lco...@web.com wrote:
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
Greg Stark gsst...@mit.edu wrote:
your query does require reading all the data.
Huh? It requires reading all the data from at least *one* of the
tables. I could conceivably be faster to read all the data from the
table with 23,980 rows and randomly pick out the necessary 33,768
rows from
On Thu, Mar 31, 2011 at 11:33 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Greg Stark gsst...@mit.edu wrote:
your query does require reading all the data.
Huh? It requires reading all the data from at least *one* of the
tables.
The query he posted a plan for was:
EXPLAIN ANALYZE
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
. I've also noticed that limit behavior which is sort of puzzling
to me.
From: pgsql-bugs-ow...@postgresql.org
[mailto:pgsql-bugs-ow...@postgresql.org] On Behalf Of Lawrence Cohan
Sent: Wednesday, March 30, 2011 10:01 AM
To: pgsql-bugs@postgresql.org
Subject: [BUGS] Postgres not using indexes
Hello
2011/3/30 Lawrence Cohan lco...@web.com:
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
Cohan; pgsql-bugs@postgresql.org
Subject: RE: [BUGS] Postgres not using indexes
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
Lawrence Cohan lco...@web.com 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:
[mailto:pavel.steh...@gmail.com]
Sent: March-30-11 12:08 PM
To: Lawrence Cohan
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] Postgres not using indexes
Hello
2011/3/30 Lawrence Cohan lco...@web.com:
We have a huge performance issues in Postgres that surfaced due to existing
indexes not being used like
Message-
From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
Sent: March-30-11 12:45 PM
To: pgsql-bugs@postgresql.org; Lawrence Cohan
Subject: Re: [BUGS] Postgres not using indexes
Lawrence Cohan lco...@web.com wrote:
We have a huge performance issues in Postgres that surfaced due
Lawrence Cohan lco...@web.com 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:
.
-Original Message-
From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
Sent: March-30-11 1:33 PM
To: pgsql-bugs@postgresql.org; Lawrence Cohan
Subject: RE: [BUGS] Postgres not using indexes
Lawrence Cohan lco...@web.com wrote:
From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov
Lawrence Cohan lco...@web.com 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
[mailto:kevin.gritt...@wicourts.gov]
Sent: March-30-11 1:33 PM
To: pgsql-bugs@postgresql.org; Lawrence Cohan
Subject: RE: [BUGS] Postgres not using indexes
Lawrence Cohan lco...@web.com wrote:
From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
[configuration advice]
If, after reading the above
';'hot_standby'
-Original Message-
From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
Sent: March-30-11 1:33 PM
To: pgsql-bugs@postgresql.org; Lawrence Cohan
Subject: RE: [BUGS] Postgres not using indexes
Lawrence Cohanlco...@web.com wrote:
From: Kevin Grittner [mailto:kevin.gritt
Harry Rossignol harry...@comcast.net 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
Lawrence Cohan lco...@web.com 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
: March-30-11 4:12 PM
To: pgsql-bugs@postgresql.org; Lawrence Cohan
Subject: Re: [BUGS] Postgres not using indexes
Lawrence Cohan lco...@web.com 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
23 matches
Mail list logo
