.
-Original Message-
From: pgsql-sql-ow...@postgresql.org [mailto:pgsql-sql-ow...@postgresql.org] On
Behalf Of ja...@aers.ca
Sent: Tuesday, July 07, 2009 3:34 PM
To: pgsql-sql@postgresql.org
Subject: [SQL] FW: Query length limitation in postgres server 8.2.9
One of our programmers has come to me
From: pgsql-sql-ow...@postgresql.org [mailto:pgsql-sql-
ow...@postgresql.org] On Behalf Of ja...@aers.ca
Sent: Thursday, July 09, 2009 1:53 PM
I've simplified the query to make it easier to look at.
This one doesn't use the index's and therefore takes about 11713ms to
return.
Have you
ja...@aers.ca writes:
I've simplified the query to make it easier to look at.
We need to see the table/index declarations. The query by itself is
just about useless.
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Thursday, July 09, 2009 11:06 AM
To: Jacob Bresciani
Cc: pgsql-sql@postgresql.org
Subject: Re: [SQL] FW: Query length limitation in postgres server
8.2.9
ja...@aers.ca writes:
I've simplified the query to make it easier
ja...@aers.ca writes:
\d search_site1_2009_03_13
And MyColumn1 is really which column?
regards, tom lane
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
ja...@aers.ca writes:
leaf_category_1
Ah. So you are wishing it would use this index:
search_site1_2009_03_13_leaf_category_1 btree (leaf_category_1,
site_id) WHERE leaf_category_1 IS NOT NULL
If I were you I'd drop the WHERE clause, which is eliminating no index
entries whatsoever
AM
To: Jacob Bresciani
Cc: pgsql-sql@postgresql.org
Subject: Re: [SQL] FW: Query length limitation in postgres server
8.2.9
ja...@aers.ca writes:
leaf_category_1
Ah. So you are wishing it would use this index:
search_site1_2009_03_13_leaf_category_1 btree (leaf_category_1,
site_id
Being just the server admin I'll forward this thought on to the dev's
for consideration.
-Original Message-
From: Hartman, Matthew [mailto:matthew.hart...@krcc.on.ca]
Sent: Thursday, July 09, 2009 10:58 AM
To: Jacob Bresciani; pgsql-sql@postgresql.org
Subject: RE: [SQL] FW: Query length
Good think I obfuscated it in one place eh :)
leaf_category_1
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Thursday, July 09, 2009 11:14 AM
To: Jacob Bresciani
Cc: pgsql-sql@postgresql.org
Subject: Re: [SQL] FW: Query length limitation in postgres server
ja...@aers.ca writes:
the data is insert once, read many so we should be fine on that side.
It's not only the insert side where you pay for so many partial indexes.
On every query of the table, the planner is going to examine every one
of those indexes and determine whether the index is
One of our programmers has come to me with a problem. On 3 new Centos 5.3
servers running Postgres 8.2.13 query's are taking 3500ms-5000ms to complete,
where the same query on an older server (same hardware, older software
revisions) the same query on the same data comes back in 50 ms. After
On Tue, Jul 7, 2009 at 11:33 PM, ja...@aers.ca wrote:
After some investigation it seems that the new server is refusing to use the
index's but if I
limit the number of arguments in the latter part of the statement to 100 then
it works as
expected in the expected amount of time using the
Greg Stark gsst...@mit.edu writes:
On Tue, Jul 7, 2009 at 11:33 PM, ja...@aers.ca wrote:
After some investigation it seems that the new server is refusing to use the
index's but if I
limit the number of arguments in the latter part of the statement to 100
then it works as
expected in the
13 matches
Mail list logo
