Re: *Regarding brin_index on required column of the table

Am 19.09.2018 um 16:43 schrieb Durgamahesh Manne:
>
>
> On Wed, Sep 19, 2018 at 8:02 PM Andreas Kretschmer 
> <andreas@a-kretschmer.de <mailto:andreas@a-kretschmer.de>> wrote:
>
>
>
>     Am 19.09.2018 um 15:51 schrieb Durgamahesh Manne:
>     > I have created BRIN index on few columns of the table without any
>     > issues. But i am unable to create BRIN index on one column of the
>     > table as i got error listed below
>     >
>     >
>     > [local]:6263 postgres@huawei=# CREATE INDEX brin_idx on huawei
>     using
>     > brin ("dFetch");
>     > ERROR:  data type boolean has no default operator class for access
>     > method "brin"
>     > HINT:  You must specify an operator class for the index or define a
>     > default operator class for the data type.
>
>     honestly, a BRIN-Index on a bool-column doesn't make much sense.
>     What do
>     you want to achive? Maybe a partial index with a where-condition
>     on that
>     column makes much more sense.
>
>
>     Regards, Andreas
>
>     -- 
>     2ndQuadrant - The PostgreSQL Support Company.
>     www.2ndQuadrant.com <http://www.2ndQuadrant.com>
>
>
>
> Hi
>
>
> I want to execute distinct query at less possible time
>
> for that reason ,Even i have already tried with BTREE indexes & HASH 
> indexes on required columns .distinct query execution time was not reduced
>
> select  distinct sub_head."vchSubmittersCode" ,rec."vchFileName" , 
> rec."vchCusipFundIDSubFundID" , rec."vchFundUnitPrice"  ,  
> sub_head."vchValuationDate" ,rec."vchAdvisorLabel" from  "table1" rec 
> join  "table2" sub_head on 
> rec."vchSubmittersCode"=sub_head."vchSubmittersCode" where 
> rec."bFetch"=false and sub_head."bFetch"=false ;
>
> Query taken around 7 minutes time to execute with BTREE indexes & HASH 
> indexes on required columns
>

try an index like

create index idx_t1 on table1 ("vchSubmittersCode") where "bFetch"=false
and
create index idx_t2 on table2 ("vchSubmittersCode") where "bFetch"=false

and check if the plan changed and the indexes are in use. You can use 
create index concurrently to prevent lockings.



Regards, Andreas

-- 
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com