Thread: PostgreSQL+Hibernate Performance

PostgreSQL+Hibernate Performance

From

"Kranti K K Parisa™"

Date:

20 August 2008, 12:26:26

Hi,

Can anyone suggest the performance tips for PostgreSQL using Hibernate.

One of the queries:

- PostgreSQL has INDEX concept and Hibernate also has Column INDEXes. Which is better among them? or creating either of them is enough? or need to create both of them?

and any more performace aspects ?

Thanks in advance.

==
KP

Re: PostgreSQL+Hibernate Performance

From

"Mark Lewis"

Date:

20 August 2008, 14:48:02

On Wed, 2008-08-20 at 17:55 +0530, Kranti K K Parisa™ wrote:
> Hi,
> 
> Can anyone suggest the performance tips for PostgreSQL using
> Hibernate.
> 
> One of the queries:
> 
> - PostgreSQL has INDEX concept and Hibernate also has Column INDEXes.
> Which is better among them? or creating either of them is enough? or
> need to create both of them?
> 
> and any more performace aspects ?

Hibernate is a library for accessing a database such as PostgreSQL.  It
does not offer any add-on capabilities to the storage layer itself.  So
when you tell Hibernate that a column should be indexed, all that it
does create the associated PostgreSQL index when you ask Hibernate to
build the DB tables for you.  This is part of Hibernate's effort to
protect you from the implementation details of the underlying database,
in order to make supporting multiple databases with the same application
code easier.

So there is no performance difference between a PG index and a Hibernate
column index, because they are the same thing.

The most useful Hibernate performance-tuning advice isn't PG-specific at
all, there are just things that you need to keep in mind when developing
for any database to avoid pathologically bad performance; those tips are
really beyond the scope of this mailing list, Google is your friend
here.

I've been the architect for an enterprise-class application for a few
years now using PostgreSQL and Hibernate together in a
performance-critical context, and honestly I can't think of one time
that I've been bitten by a PG-specific performance issue (a lot of
performance issues with Hibernate that affected all databases though;
you need to know what you're doing to make Hibernate apps that run fast.
If you do run into problems, you can figure out the actual SQL that
Hibernate is issuing and do the normal PostgreSQL explain analyze on it;
usually caused by a missing index.

-- Mark

Re: PostgreSQL+Hibernate Performance

From

"Kranti K K Parisa™"

Date:

20 August 2008, 15:03:12

Hi Mark,

Thank you very much for the information. I will analyse the DB structure and create indexes on PG directly.
Are you using any connection pooling like DBCP? or PG POOL?

Regards, KP

On Wed, Aug 20, 2008 at 8:05 PM, Mark Lewis <mark.lewis@mir3.com> wrote:

On Wed, 2008-08-20 at 17:55 +0530, Kranti K K Parisa™ wrote:
> Hi,
>
> Can anyone suggest the performance tips for PostgreSQL using
> Hibernate.
>
> One of the queries:
>
> - PostgreSQL has INDEX concept and Hibernate also has Column INDEXes.
> Which is better among them? or creating either of them is enough? or
> need to create both of them?
>
> and any more performace aspects ?

Hibernate is a library for accessing a database such as PostgreSQL. It
does not offer any add-on capabilities to the storage layer itself. So
when you tell Hibernate that a column should be indexed, all that it
does create the associated PostgreSQL index when you ask Hibernate to
build the DB tables for you. This is part of Hibernate's effort to
protect you from the implementation details of the underlying database,
in order to make supporting multiple databases with the same application
code easier.

So there is no performance difference between a PG index and a Hibernate
column index, because they are the same thing.

The most useful Hibernate performance-tuning advice isn't PG-specific at
all, there are just things that you need to keep in mind when developing
for any database to avoid pathologically bad performance; those tips are
really beyond the scope of this mailing list, Google is your friend
here.

I've been the architect for an enterprise-class application for a few
years now using PostgreSQL and Hibernate together in a
performance-critical context, and honestly I can't think of one time
that I've been bitten by a PG-specific performance issue (a lot of
performance issues with Hibernate that affected all databases though;
you need to know what you're doing to make Hibernate apps that run fast.
If you do run into problems, you can figure out the actual SQL that
Hibernate is issuing and do the normal PostgreSQL explain analyze on it;
usually caused by a missing index.

-- Mark

--

Best Regards
Kranti Kiran Kumar Parisa
M: +91 - 9391 - 438 - 738
+91 - 9849 - 625 - 625

Re: PostgreSQL+Hibernate Performance

From

"Nikolas Everett"

Date:

20 August 2008, 15:06:03

The only thing thats bitten me about hibernate + postgres is that when inserting into partitioned tables, postgres does not reply with the number of rows that hibernate expected. My current (not great) solution is to define a specific SQLInsert annotation and tell it not to do any checking like so:

@SQLInsert(sql="insert into bigmetric (account_id, a, b, timestamp, id) values (?, ?, ?, ?, ?)", check=ResultCheckStyle.NONE)

I just steel the sql from the SQL from hibernate's logs.

On Wed, Aug 20, 2008 at 10:40 AM, Mark Lewis <mark.lewis@mir3.com> wrote:

On Wed, 2008-08-20 at 17:55 +0530, Kranti K K Parisa™ wrote:
> Hi,
>
> Can anyone suggest the performance tips for PostgreSQL using
> Hibernate.
>
> One of the queries:
>
> - PostgreSQL has INDEX concept and Hibernate also has Column INDEXes.
> Which is better among them? or creating either of them is enough? or
> need to create both of them?
>
> and any more performace aspects ?

Hibernate is a library for accessing a database such as PostgreSQL. It
does not offer any add-on capabilities to the storage layer itself. So
when you tell Hibernate that a column should be indexed, all that it
does create the associated PostgreSQL index when you ask Hibernate to
build the DB tables for you. This is part of Hibernate's effort to
protect you from the implementation details of the underlying database,
in order to make supporting multiple databases with the same application
code easier.

So there is no performance difference between a PG index and a Hibernate
column index, because they are the same thing.

The most useful Hibernate performance-tuning advice isn't PG-specific at
all, there are just things that you need to keep in mind when developing
for any database to avoid pathologically bad performance; those tips are
really beyond the scope of this mailing list, Google is your friend
here.

I've been the architect for an enterprise-class application for a few
years now using PostgreSQL and Hibernate together in a
performance-critical context, and honestly I can't think of one time
that I've been bitten by a PG-specific performance issue (a lot of
performance issues with Hibernate that affected all databases though;
you need to know what you're doing to make Hibernate apps that run fast.
If you do run into problems, you can figure out the actual SQL that
Hibernate is issuing and do the normal PostgreSQL explain analyze on it;
usually caused by a missing index.

-- Mark

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: PostgreSQL+Hibernate Performance

From

"Kranti K K Parisa™"

Date:

20 August 2008, 15:12:29

creating multiple indexes on same column will effect performance?
for example:

index1 : column1, column2, column3
index2: column1
index3: column2,
index4: column3
index5: column1,column2

which means, i am trying fire the SQL queries keeping columns in the where conditions. and the possibilities are like the above.

if we create such indexes will it effect on performance?
and what is the best go in this case?

On Wed, Aug 20, 2008 at 8:10 PM, Mark Lewis <mark.lewis@mir3.com> wrote:

On Wed, 2008-08-20 at 17:55 +0530, Kranti K K Parisa™ wrote:
> Hi,
>
> Can anyone suggest the performance tips for PostgreSQL using
> Hibernate.
>
> One of the queries:
>
> - PostgreSQL has INDEX concept and Hibernate also has Column INDEXes.
> Which is better among them? or creating either of them is enough? or
> need to create both of them?
>
> and any more performace aspects ?

Hibernate is a library for accessing a database such as PostgreSQL. It
does not offer any add-on capabilities to the storage layer itself. So
when you tell Hibernate that a column should be indexed, all that it
does create the associated PostgreSQL index when you ask Hibernate to
build the DB tables for you. This is part of Hibernate's effort to
protect you from the implementation details of the underlying database,
in order to make supporting multiple databases with the same application
code easier.

So there is no performance difference between a PG index and a Hibernate
column index, because they are the same thing.

The most useful Hibernate performance-tuning advice isn't PG-specific at
all, there are just things that you need to keep in mind when developing
for any database to avoid pathologically bad performance; those tips are
really beyond the scope of this mailing list, Google is your friend
here.

I've been the architect for an enterprise-class application for a few
years now using PostgreSQL and Hibernate together in a
performance-critical context, and honestly I can't think of one time
that I've been bitten by a PG-specific performance issue (a lot of
performance issues with Hibernate that affected all databases though;
you need to know what you're doing to make Hibernate apps that run fast.
If you do run into problems, you can figure out the actual SQL that
Hibernate is issuing and do the normal PostgreSQL explain analyze on it;
usually caused by a missing index.

-- Mark

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

--

Best Regards
Kranti Kiran Kumar Parisa
M: +91 - 9391 - 438 - 738
+91 - 9849 - 625 - 625

Re: PostgreSQL+Hibernate Performance

From

Matthew Wakeling

Date:

20 August 2008, 15:24:18

On Wed, 20 Aug 2008, Kranti K K Parisa™ wrote:
> creating multiple indexes on same column will effect performance?
>  for example:
>
> index1 : column1, column2, column3
> index2: column1
> index3: column2,
> index4: column3
> index5: column1,column2

The sole purpose of indexes is to affect performance.

However, if you have index1, there is no point in having index2 or index5.

Matthew

--
Isn't "Microsoft Works" something of a contradiction?

Re: PostgreSQL+Hibernate Performance

From

Mark Lewis

Date:

20 August 2008, 15:25:10

The tradeoffs for multiple indexes are more or less as follows:

1. Having the right indexes makes queries faster, often dramatically so.

2. But more indexes makes inserts/updates slower, although generally not
dramatically slower.

3. Each index requires disk space.  With several indexes, you can easily
have more of your disk taken up by indexes than with actual data.

I would be careful to only create the indexes you need, but it's
probably worse to have too few indexes than too many.  Depends on your
app though.

-- Mark

On Wed, 2008-08-20 at 20:40 +0530, Kranti K K Parisa™ wrote:
> creating multiple indexes on same column will effect performance?
>  for example:
>
> index1 : column1, column2, column3
> index2: column1
> index3: column2,
> index4: column3
> index5: column1,column2
>
> which means, i am trying fire the SQL queries keeping columns in the
> where conditions. and the possibilities are like the above.
>
> if we create such indexes will it effect on performance?
> and what is the best go in this case?
>
>
> On Wed, Aug 20, 2008 at 8:10 PM, Mark Lewis <mark.lewis@mir3.com>
> wrote:
>         On Wed, 2008-08-20 at 17:55 +0530, Kranti K K Parisa™ wrote:
>
>
>         > Hi,
>         >
>         > Can anyone suggest the performance tips for PostgreSQL using
>         > Hibernate.
>         >
>         > One of the queries:
>         >
>         > - PostgreSQL has INDEX concept and Hibernate also has Column
>         INDEXes.
>         > Which is better among them? or creating either of them is
>         enough? or
>         > need to create both of them?
>         >
>         > and any more performace aspects ?
>
>
>
>         Hibernate is a library for accessing a database such as
>         PostgreSQL.  It
>         does not offer any add-on capabilities to the storage layer
>         itself.  So
>         when you tell Hibernate that a column should be indexed, all
>         that it
>         does create the associated PostgreSQL index when you ask
>         Hibernate to
>         build the DB tables for you.  This is part of Hibernate's
>         effort to
>         protect you from the implementation details of the underlying
>         database,
>         in order to make supporting multiple databases with the same
>         application
>         code easier.
>
>         So there is no performance difference between a PG index and a
>         Hibernate
>         column index, because they are the same thing.
>
>         The most useful Hibernate performance-tuning advice isn't
>         PG-specific at
>         all, there are just things that you need to keep in mind when
>         developing
>         for any database to avoid pathologically bad performance;
>         those tips are
>         really beyond the scope of this mailing list, Google is your
>         friend
>         here.
>
>         I've been the architect for an enterprise-class application
>         for a few
>         years now using PostgreSQL and Hibernate together in a
>         performance-critical context, and honestly I can't think of
>         one time
>         that I've been bitten by a PG-specific performance issue (a
>         lot of
>         performance issues with Hibernate that affected all databases
>         though;
>         you need to know what you're doing to make Hibernate apps that
>         run fast.
>         If you do run into problems, you can figure out the actual SQL
>         that
>         Hibernate is issuing and do the normal PostgreSQL explain
>         analyze on it;
>         usually caused by a missing index.
>
>         -- Mark
>
>
>
>
>         --
>         Sent via pgsql-performance mailing list
>         (pgsql-performance@postgresql.org)
>         To make changes to your subscription:
>         http://www.postgresql.org/mailpref/pgsql-performance
>
>
>
> --
>
> Best Regards
> Kranti Kiran Kumar Parisa
> M: +91 - 9391 - 438 - 738
> +91 - 9849 - 625 - 625
>
>

Re: PostgreSQL+Hibernate Performance

From

Mark Lewis

Date:

20 August 2008, 15:29:56

Yes, we use connection pooling.  As I recall Hibernate ships with c3p0
connection pooling built-in, which is what we use.  We were happy enough
with c3p0 that we ended up moving our other non-hibernate apps over to
it, away from DBCP.

pgpool does connection pooling at a socket level instead of in a local
library level, so really it's a very different thing.  If your app is
the only thing talking to this database, and you don't have a
multi-database configuration, then it will be easier for you to use a
Java-based connection pooling library like c3p0 or DBCP than to use
pgpool.

-- Mark

On Wed, 2008-08-20 at 20:32 +0530, Kranti K K Parisa™ wrote:
> Hi Mark,
>
> Thank you very much for the information. I will analyse the DB
> structure and create indexes on PG directly.
> Are you using any connection pooling like DBCP? or PG POOL?
>
> Regards, KP
>
>
> On Wed, Aug 20, 2008 at 8:05 PM, Mark Lewis <mark.lewis@mir3.com>
> wrote:
>
>         On Wed, 2008-08-20 at 17:55 +0530, Kranti K K Parisa™ wrote:
>         > Hi,
>         >
>         > Can anyone suggest the performance tips for PostgreSQL using
>         > Hibernate.
>         >
>         > One of the queries:
>         >
>         > - PostgreSQL has INDEX concept and Hibernate also has Column
>         INDEXes.
>         > Which is better among them? or creating either of them is
>         enough? or
>         > need to create both of them?
>         >
>         > and any more performace aspects ?
>
>
>         Hibernate is a library for accessing a database such as
>         PostgreSQL.  It
>         does not offer any add-on capabilities to the storage layer
>         itself.  So
>         when you tell Hibernate that a column should be indexed, all
>         that it
>         does create the associated PostgreSQL index when you ask
>         Hibernate to
>         build the DB tables for you.  This is part of Hibernate's
>         effort to
>         protect you from the implementation details of the underlying
>         database,
>         in order to make supporting multiple databases with the same
>         application
>         code easier.
>
>         So there is no performance difference between a PG index and a
>         Hibernate
>         column index, because they are the same thing.
>
>         The most useful Hibernate performance-tuning advice isn't
>         PG-specific at
>         all, there are just things that you need to keep in mind when
>         developing
>         for any database to avoid pathologically bad performance;
>         those tips are
>         really beyond the scope of this mailing list, Google is your
>         friend
>         here.
>
>         I've been the architect for an enterprise-class application
>         for a few
>         years now using PostgreSQL and Hibernate together in a
>         performance-critical context, and honestly I can't think of
>         one time
>         that I've been bitten by a PG-specific performance issue (a
>         lot of
>         performance issues with Hibernate that affected all databases
>         though;
>         you need to know what you're doing to make Hibernate apps that
>         run fast.
>         If you do run into problems, you can figure out the actual SQL
>         that
>         Hibernate is issuing and do the normal PostgreSQL explain
>         analyze on it;
>         usually caused by a missing index.
>
>         -- Mark
>
>
>
> --
>
> Best Regards
> Kranti Kiran Kumar Parisa
> M: +91 - 9391 - 438 - 738
> +91 - 9849 - 625 - 625
>
>

Re: PostgreSQL+Hibernate Performance

From

"Kranti K K Parisa™"

Date:

21 August 2008, 06:59:49

Thanks Mark,

We are using DBCP and i found something about pgpool in some forum threads, which gave me queries on it. But I am clear now.

On Wed, Aug 20, 2008 at 8:59 PM, Mark Lewis <mark.lewis@mir3.com> wrote:

Yes, we use connection pooling. As I recall Hibernate ships with c3p0
connection pooling built-in, which is what we use. We were happy enough
with c3p0 that we ended up moving our other non-hibernate apps over to
it, away from DBCP.

pgpool does connection pooling at a socket level instead of in a local
library level, so really it's a very different thing. If your app is
the only thing talking to this database, and you don't have a
multi-database configuration, then it will be easier for you to use a
Java-based connection pooling library like c3p0 or DBCP than to use
pgpool.

-- Mark

On Wed, 2008-08-20 at 20:32 +0530, Kranti K K Parisa™ wrote:
> Hi Mark,
>
> Thank you very much for the information. I will analyse the DB
> structure and create indexes on PG directly.
> Are you using any connection pooling like DBCP? or PG POOL?
>
> Regards, KP
>
>
> On Wed, Aug 20, 2008 at 8:05 PM, Mark Lewis <mark.lewis@mir3.com>
> wrote:
>
> On Wed, 2008-08-20 at 17:55 +0530, Kranti K K Parisa™ wrote:
> > Hi,
> >
> > Can anyone suggest the performance tips for PostgreSQL using
> > Hibernate.
> >
> > One of the queries:
> >
> > - PostgreSQL has INDEX concept and Hibernate also has Column
> INDEXes.
> > Which is better among them? or creating either of them is
> enough? or
> > need to create both of them?
> >
> > and any more performace aspects ?
>
>
> Hibernate is a library for accessing a database such as
> PostgreSQL. It
> does not offer any add-on capabilities to the storage layer
> itself. So
> when you tell Hibernate that a column should be indexed, all
> that it
> does create the associated PostgreSQL index when you ask
> Hibernate to
> build the DB tables for you. This is part of Hibernate's
> effort to
> protect you from the implementation details of the underlying
> database,
> in order to make supporting multiple databases with the same
> application
> code easier.
>
> So there is no performance difference between a PG index and a
> Hibernate
> column index, because they are the same thing.
>
> The most useful Hibernate performance-tuning advice isn't
> PG-specific at
> all, there are just things that you need to keep in mind when
> developing
> for any database to avoid pathologically bad performance;
> those tips are
> really beyond the scope of this mailing list, Google is your
> friend
> here.
>
> I've been the architect for an enterprise-class application
> for a few
> years now using PostgreSQL and Hibernate together in a
> performance-critical context, and honestly I can't think of
> one time
> that I've been bitten by a PG-specific performance issue (a
> lot of
> performance issues with Hibernate that affected all databases
> though;
> you need to know what you're doing to make Hibernate apps that
> run fast.
> If you do run into problems, you can figure out the actual SQL
> that
> Hibernate is issuing and do the normal PostgreSQL explain
> analyze on it;
> usually caused by a missing index.
>
> -- Mark
>
>
>
> --
>
> Best Regards
> Kranti Kiran Kumar Parisa
> M: +91 - 9391 - 438 - 738
> +91 - 9849 - 625 - 625
>
>

--

Best Regards
Kranti Kiran Kumar Parisa
M: +91 - 9391 - 438 - 738
+91 - 9849 - 625 - 625

Re: PostgreSQL+Hibernate Performance

From

"Kranti K K Parisa™"

Date:

21 August 2008, 07:04:00

Thanks Matthew,

does that mean i can just have index1, index3, index4?

On Wed, Aug 20, 2008 at 8:54 PM, Matthew Wakeling <matthew@flymine.org> wrote:

On Wed, 20 Aug 2008, Kranti K K Parisa™ wrote:
creating multiple indexes on same column will effect performance?
for example:

index1 : column1, column2, column3
index2: column1
index3: column2,
index4: column3
index5: column1,column2

The sole purpose of indexes is to affect performance.

However, if you have index1, there is no point in having index2 or index5.

Matthew

--
Isn't "Microsoft Works" something of a contradiction?
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

--

Best Regards
Kranti Kiran Kumar Parisa
M: +91 - 9391 - 438 - 738
+91 - 9849 - 625 - 625

Re: PostgreSQL+Hibernate Performance

From

Mark Lewis

Date:

21 August 2008, 14:02:08

On Thu, 2008-08-21 at 12:33 +0530, Kranti K K Parisa™ wrote:

> On Wed, Aug 20, 2008 at 8:54 PM, Matthew Wakeling
> <matthew@flymine.org> wrote:
>         On Wed, 20 Aug 2008, Kranti K K Parisa™ wrote:
>                 creating multiple indexes on same column will effect
>                 performance?
>                  for example:
>
>                 index1 : column1, column2, column3
>                 index2: column1
>                 index3: column2,
>                 index4: column3
>                 index5: column1,column2
>
>
>         The sole purpose of indexes is to affect performance.
>
>         However, if you have index1, there is no point in having
>         index2 or index5.
>
>         Matthew
>
> Thanks Matthew,
>
> does that mean i can just have index1, index3, index4?
>

(trying to get the thread back into newest-comments-last order)

Well, yes you can get away with just index1, index3 and index4, and it
may well be the optimal solution for you, but it's not entirely
clear-cut.

It's true that PG can use index1 to satisfy queries of the form "SELECT
x FROM y WHERE column1=somevalue" or "column1=a AND column2=b".  It will
not be as fast as an index lookup from a single index, but depending on
the size of the tables/indexes and the selectivity of leading column(s)
in the index, the difference in speed may be trivial.

On the other hand, if you have individual indexes on column1, column2
and column3 but no multi-column index, PG can combine the individual
indexes in memory with a bitmap.  This is not as fast as a normal lookup
in the multi-column index would be, but can still be a big win over not
having an index at all.

To make an educated decision you might want to read over some of the
online documentation about indexes, in particular these two sections:

http://www.postgresql.org/docs/8.3/interactive/indexes-multicolumn.html

and

http://www.postgresql.org/docs/8.3/interactive/indexes-bitmap-scans.html

-- Mark

Re: PostgreSQL+Hibernate Performance

From

"Kranti K K Parisa™"

Date:

22 August 2008, 05:52:25

Hi Mark,

Thanks again for the info.
I shall create diff sets of indexes and see the query execution time.
And one of such tables might get around 700,000 records over a period of 4-5 months. So what kind of other measures I need to focus on.
I thought of the following
1) Indexes
2) Better Hardware (RAM & HDD)

And how can i estimate the size of the row? is it like based on the data types of the columns i have in the table?
Do you have any info to guide me on this?

On Thu, Aug 21, 2008 at 7:32 PM, Mark Lewis <mark.lewis@mir3.com> wrote:

On Thu, 2008-08-21 at 12:33 +0530, Kranti K K Parisa™ wrote:

> On Wed, Aug 20, 2008 at 8:54 PM, Matthew Wakeling
> <matthew@flymine.org> wrote:
> On Wed, 20 Aug 2008, Kranti K K Parisa™ wrote:
> creating multiple indexes on same column will effect
> performance?
> for example:
>
> index1 : column1, column2, column3
> index2: column1
> index3: column2,
> index4: column3
> index5: column1,column2
>
>
> The sole purpose of indexes is to affect performance.
>
> However, if you have index1, there is no point in having
> index2 or index5.
>
> Matthew
>
> Thanks Matthew,
>
> does that mean i can just have index1, index3, index4?
>

(trying to get the thread back into newest-comments-last order)

Well, yes you can get away with just index1, index3 and index4, and it
may well be the optimal solution for you, but it's not entirely
clear-cut.

It's true that PG can use index1 to satisfy queries of the form "SELECT
x FROM y WHERE column1=somevalue" or "column1=a AND column2=b". It will
not be as fast as an index lookup from a single index, but depending on
the size of the tables/indexes and the selectivity of leading column(s)
in the index, the difference in speed may be trivial.

On the other hand, if you have individual indexes on column1, column2
and column3 but no multi-column index, PG can combine the individual
indexes in memory with a bitmap. This is not as fast as a normal lookup
in the multi-column index would be, but can still be a big win over not
having an index at all.

To make an educated decision you might want to read over some of the
online documentation about indexes, in particular these two sections:

http://www.postgresql.org/docs/8.3/interactive/indexes-multicolumn.html

and

http://www.postgresql.org/docs/8.3/interactive/indexes-bitmap-scans.html

-- Mark

--

Best Regards
Kranti Kiran Kumar Parisa
M: +91 - 9391 - 438 - 738
+91 - 9849 - 625 - 625