asically we need to understand how the data is organized within table and
across schema or system.
To begin with, maybe below links could provide some insights:
http://www.postgresql.org/docs/current/static/indexes-multicolumn.html
http://www.postgresql.org/docs/current/static/indexes-bitmap-sca
indexes based on exact order of
predicates specified in query.
Instead the idea should be consider the predicate which is going to do
filter out the results.
Likewise we should consider all possible uses of index columns across all
queries and then decide on the
order of columns for the composite index to be created.
Whats your take on this?
--
Regards,
Chetan Suttraway
EnterpriseDB <http://www.enterprisedb.com/>, The Enterprise
PostgreSQL<http://www.enterprisedb.com/>
company.
On Fri, Mar 25, 2011 at 12:39 PM, Adarsh Sharma wrote:
> Chetan Suttraway wrote:
>
>
>
> On Fri, Mar 25, 2011 at 12:05 PM, Adarsh Sharma
> wrote:
>
>> Dear all,
>>
>> Today I got to run a query internally from my application by more than 10
>> co
2 USING btree (clause_id, doc_id,
> sentence_id);
>
> I don't know why it not uses the index scan for clause2 table.
>
>
In this case, there are no predicates or filters on individual table. (maybe
something like c.source_id=10)
so either of the 2 tables will have to
:). Slow query operates with data mostly on disk, while fast one with
> data in memory.
>
> yeah. maybe the easiest way, is to start a fresh session and fire the
queries.
> Best regards, Vitalii Tymchyshyn
>
--
Regards,
Chetan Suttraway
EnterpriseDB <http://www.enterprisedb.com/>, The Enterprise
PostgreSQL<http://www.enterprisedb.com/>
company.
s like to give expected results. Also note that the where clause
"is null" is really required and is not an
optional predicate.
> regards
> Tomas
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes
gt;
> What is the significance of 1 here.
>
> Thanks , Adarsh
> **
>
> Best regards, Vitalii Tymchyshyn.
>
>
>
Its the inverted logic for finding crawled_page_id not matching with
source_id.
Actually, the idea was to force index scan on clause2 though.
--
Regards,
Chet
using t1_b on t1 (cost=0.00..76.35 rows=2140
width=4)
-> Index Scan using t2_d on t2 (cost=0.00..12.75 rows=713
width=4)
Index Cond: (public.t1.b < public.t2.d)
(11 rows)
This looks like to a acceptable.
Please try this above query with your setup and post the explain output.
--
Regards,
Chetan Suttraway
EnterpriseDB <http://www.enterprisedb.com/>, The Enterprise
PostgreSQL<http://www.enterprisedb.com/>
company.
2 rows=31876196
> width=4)
>-> Seq Scan on clause2 c (cost=0.00..771182.96
> rows=31876196 width=4)
> (6 rows)
>
>
> Please guide me how to make the above query run faster as I am not able to
> do that.
>
>
> Thanks, Adarsh
&g
On Sun, Feb 27, 2011 at 2:43 AM, Josh Berkus wrote:
> On 2/25/11 5:31 AM, Sam Wong wrote:
> > I found that "LIKE", "= ANY (...)", "LIKE .. OR LIKE .." against a text
> > field used the index correctly, but not "LIKE ANY (...)". Would that be a
> > bug?
>
> No, it would be a TODO. This is a known
10 matches
Mail list logo
