From: Magers, James <James.Magers@turner.com>
To: Tomas Vondra <tv@fuzzy.cz>
Cc: Thomas Kellerer <spam_eater@gmx.net>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Query Performance question
Date: Mon, 14 Jul 2014 17:15:54 +0000
Message-ID: <3658dc09a48248edbb137093cf0b3029@CO2PR07MB601.namprd07.prod.outlook.com> (raw)
In-Reply-To: <cd6e01a422112f2570964d827a34af4f.squirrel@sq.gransy.com>
References: <1405292142269.59034@turner.com>
<53C32B20.8010100@fuzzy.cz>
<1405304448354.64039@turner.com>
<lpvviu$en3$1@ger.gmane.org>
<b5a078be76e74517b341a9b76a3c136c@CO2PR07MB601.namprd07.prod.outlook.com>
<lq0n2j$60o$1@ger.gmane.org>
<1bd268ebd99945d6b16d12cca39893c8@CO2PR07MB601.namprd07.prod.outlook.com>
<ed5fd6300b0de41e9c9169f8d6f05be7.squirrel@sq.gransy.com>
<5699436b456242b699889f7d24d91227@CO2PR07MB601.namprd07.prod.outlook.com>
<cd6e01a422112f2570964d827a34af4f.squirrel@sq.gransy.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
Thank you Tomas. I did execute the queries against a dataset that was representative of what we expect the production dataset to have. By higher volume I meant more transactions happening against the data, We would expect the data size to increase over time and when we executed against a dataset that was about 4x larger the index scan was selected to perform the lookup versus the bitmap heap scan. The scan of the both the smaller and larger datasets were returning in similar times between the two groups of tests. This is part of the reason that I was thinking that the bitmap heap scan may not be as efficient since 4 times the data returned in just a little more time using the index scan.
Thank you,
James
-----Original Message-----
From: Tomas Vondra [mailto:tv@fuzzy.cz]
Sent: Monday, July 14, 2014 12:29 PM
To: Magers, James
Cc: Tomas Vondra; Thomas Kellerer; pgsql-performance@postgresql.org
Subject: RE: [PERFORM] Query Performance question
On 14 Červenec 2014, 18:02, Magers, James wrote:
> Tomas,
>
> Thank you for the recommendation. In this case, The bitmap scan runs
> quite quickly, however in production were data may or may not be cached
> and at higher volumes I am trying to ensure the process will continue to
> execute efficiently and reduce the impact of the process on other
> processes running against the database.
That's why it's important to do the testing with representative amount of
data. Testing the queries on significantly reduced dataset is pointless,
because the optimizer will do different decisions.
> My assessment is based on my experiences with the scans. Does your
> experience provide you with a different assessment of the scan types and
> how efficient they may be?
No. Because I don't have your data. And it seems that your assessment is
based on experience with dataset that's very different from your expected
production dataset, which means the experience is not directly applicable.
The optimizer considers the size of the dataset when choosing the plan.
regards
Tomas
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: James.Magers@turner.com, tv@fuzzy.cz, spam_eater@gmx.net
Subject: Re: Query Performance question
In-Reply-To: <3658dc09a48248edbb137093cf0b3029@CO2PR07MB601.namprd07.prod.outlook.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox