Comment 4 for bug 1506738

my test for postgresql shows that, postgresql (9.3) is not affected because the command query-samples can response very quick instead of timeout, which mysql couldn't

with my patch applied, the postgresql runs well as before, no significant performance impact observed (only test query-samples because the patch only affects that API):

PostgreSQL:

with log_min_duration_statement = 0 in /etc/postgresql/9.3/main/postgresql.conf
5M samples and 100K resources

before change:
$ time ceilometer query-samples -l 1000000 -f '{"and":[{"<=":{"timestamp":"2015-10-26T04:46:48"}},{">=":{"timestamp":"2015-10-26T03:46:48"}}]}'

real 0m11.183s
user 0m0.537s
sys 0m0.087s

2015-10-25 22:56:04 MDT LOG: duration: 4.177 ms statement: SELECT anon_1.id AS anon_1_id, anon_1.counter_name AS anon_1_counter_name, anon_1.counter_type AS anon_1_counter_type, anon_1.counter_unit AS anon_1_counter_unit, anon_1.counter_volume AS anon_1_counter_volume, anon_1.resource_id AS anon_1_resource_id, anon_1.source_id AS anon_1_source_id, anon_1.user_id AS anon_1_user_id, anon_1.project_id AS anon_1_project_id, anon_1.resource_metadata AS anon_1_resource_metadata, anon_1.internal_id AS anon_1_internal_id, anon_1.timestamp AS anon_1_timestamp, anon_1.message_id AS anon_1_message_id, anon_1.message_signature AS anon_1_message_signature, anon_1.recorded_at AS anon_1_recorded_at
    FROM (SELECT sample.id AS id, meter.name AS counter_name, meter.type AS counter_type, meter.unit AS counter_unit, sample.volume AS counter_volume, resource.resource_id AS resource_id, resource.source_id AS source_id, resource.user_id AS user_id, resource.project_id AS project_id, resource.resource_metadata AS resource_metadata, resource.internal_id AS internal_id, sample.timestamp AS timestamp, sample.message_id AS message_id, sample.message_signature AS message_signature, sample.recorded_at AS recorded_at
    FROM sample JOIN meter ON sample.meter_id = meter.id JOIN resource ON sample.resource_id = resource.internal_id) AS anon_1
    WHERE anon_1.timestamp <= '2015-10-26T04:46:48'::timestamp AND anon_1.timestamp >= '2015-10-26T03:46:48'::timestamp ORDER BY anon_1.timestamp DESC
     LIMIT 1000000

after change:

$ time ceilometer query-samples -l 1000000 -f '{"and":[{"<=":{"timestamp":"2015-10-26T04:46:48"}},{">=":{"timestamp":"2015-10-26T03:46:48"}}]}'

real 0m1.009s
user 0m0.500s
sys 0m0.081s

2015-10-25 22:53:08 MDT LOG: duration: 3.658 ms statement: SELECT sample.timestamp AS sample_timestamp, sample.recorded_at AS sample_recorded_at, sample.message_id AS sample_message_id, sample.message_signature AS sample_message_signature, sample.volume AS counter_volume, meter.name AS counter_name, meter.type AS counter_type, meter.unit AS counter_unit, resource.source_id AS resource_source_id, resource.user_id AS resource_user_id, resource.project_id AS resource_project_id, resource.resource_metadata AS resource_resource_metadata, resource.resource_id AS resource_resource_id
    FROM sample JOIN meter ON meter.id = sample.meter_id JOIN resource ON resource.internal_id = sample.resource_id
    WHERE sample.timestamp <= '2015-10-26T04:46:48'::timestamp AND sample.timestamp >= '2015-10-26T03:46:48'::timestamp ORDER BY sample.timestamp DESC
     LIMIT 1000000