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
the data is insert once, read many so we should be fine on that side.
I've past this on to the dev's and I'll let you know when I get feed
back. Thanks for your input Tom (and the others).
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Thursday, July 09, 2009 11:29 AM
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
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 l
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 >
8.2
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
\d search_site1_2009_03_13
Table "public.search_site1_2009_03_13"
Column| Type | Modifiers
--++---
item_id | bigint | not null
transaction_id | bigint
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
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.
EXPLAIN ANALYZE SELECT * FROM MyTable1 where (MyColumn1 IN
(4305,112798,112799,112800,112801,112802,112803,112804,112770,112771,112772,112773,112774,112775,
112776
Rob Sargent wrote:
I have to restructure some tables, coalescing common elements from three
tables (sub-classes) into a single table (super-class). Each source
table has a text field which actually gets stuffed with a largish (1Mb+)
blob of xml.
Is there any way to simply, um, er, transplant
11 matches
Mail list logo
