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 potentially usable.
W
09, 2009 11:29 AM
To: Jacob Bresciani
Cc: pgsql-sql@postgresql.org
Subject: Re: [SQL] FW: Query length limitation in postgres server >
8.2.9
writes:
> leaf_category_1
Ah. So you are wishing it would use this index:
"search_site1_2009_03_13_leaf_category_1" btree (
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 (since the c
ery length limitation in postgres server >
8.2.9
> 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 on
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
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
tree (leaf_category_1,
site_id) WHERE leaf_category_1 IS NOT NULL
"search_site1_2009_03_13_seller_user_id" btree (seller_user_id,
site_id) WHERE seller_user_id IS NOT NULL
"search_site1_2009_03_13_upc_code" btree (upc_code, site_id) WHERE
upc_code IS NOT NULL
-Origi
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 your subscriptio
> 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.
Hav
ersion has 101 items.
-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 pro
Greg Stark writes:
> On Tue, Jul 7, 2009 at 11:33 PM, 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
On Tue, Jul 7, 2009 at 11:33 PM, 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 indexs.
Ugh
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 s
13 matches
Mail list logo
