Bump the minimum version of PostgreSQL to 9.3 #34520
Conversation
JOIN pg_attribute a | ||
ON a.attrelid = i.indrelid | ||
AND a.attnum = i.indkey[i.idx] | ||
ORDER BY i.idx |
kamipo
Nov 25, 2018
Member
Is this query deterministic order even if the ORDER BY is removed?
Is this query deterministic order even if the ORDER BY is removed?
yahonda
Nov 25, 2018
Author
Contributor
Thanks for the comment.
In my environment, it returns the primary key order as expected without order by but It does not look like deterministic since it does not Sort
at the end of the query.
Was thinking about adding order by a.attnum
but it just shows the column
order of the table, not the index key order.
create_table :countries_treaties, force: true, primary_key: [:country_id, :treaty_id] do |t|
t.string :country_id, null: false
t.string :treaty_id, null: false
end
- Without
ORDER BY i.idx
activerecord_unittest=# SELECT a.attname
FROM (
SELECT indrelid, indkey, generate_subscripts(indkey, 1) idx
FROM pg_index
WHERE indrelid = 'countries_treaties'::regclass
AND indisprimary
) i
JOIN pg_attribute a
ON a.attrelid = i.indrelid
AND a.attnum = i.indkey[i.idx];
attname
------------
country_id
treaty_id
(2 rows)
activerecord_unittest=# explain SELECT a.attname
activerecord_unittest-# FROM (
activerecord_unittest(# SELECT indrelid, indkey, generate_subscripts(indkey, 1) idx
activerecord_unittest(# FROM pg_index
activerecord_unittest(# WHERE indrelid = 'countries_treaties'::regclass
activerecord_unittest(# AND indisprimary
activerecord_unittest(# ) i
activerecord_unittest-# JOIN pg_attribute a
activerecord_unittest-# ON a.attrelid = i.indrelid
activerecord_unittest-# AND a.attnum = i.indkey[i.idx];
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------
Hash Join (cost=329.65..357.92 rows=43 width=64)
Hash Cond: ((pg_index.indrelid = a.attrelid) AND (pg_index.indkey[(generate_subscripts(pg_index.indkey, 1))] = a.attnum))
-> ProjectSet (cost=0.27..13.30 rows=1000 width=34)
-> Index Scan using pg_index_indrelid_index on pg_index (cost=0.27..8.29 rows=1 width=30)
Index Cond: (indrelid = '207561'::oid)
Filter: indisprimary
-> Hash (cost=218.75..218.75 rows=7375 width=70)
-> Seq Scan on pg_attribute a (cost=0.00..218.75 rows=7375 width=70)
(8 rows)
activerecord_unittest=#
- WITH
ORDER BY i.idx
activerecord_unittest=# explain SELECT a.attname
FROM (
SELECT indrelid, indkey, generate_subscripts(indkey, 1) idx
FROM pg_index
WHERE indrelid = 'countries_treaties'::regclass
AND indisprimary
) i
JOIN pg_attribute a
ON a.attrelid = i.indrelid
AND a.attnum = i.indkey[i.idx] ORDER BY i.idx;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------
Sort (cost=359.09..359.20 rows=43 width=68)
Sort Key: (generate_subscripts(pg_index.indkey, 1))
-> Hash Join (cost=329.65..357.92 rows=43 width=68)
Hash Cond: ((pg_index.indrelid = a.attrelid) AND (pg_index.indkey[(generate_subscripts(pg_index.indkey, 1))] = a.attnum))
-> ProjectSet (cost=0.27..13.30 rows=1000 width=34)
-> Index Scan using pg_index_indrelid_index on pg_index (cost=0.27..8.29 rows=1 width=30)
Index Cond: (indrelid = '207561'::oid)
Filter: indisprimary
-> Hash (cost=218.75..218.75 rows=7375 width=70)
-> Seq Scan on pg_attribute a (cost=0.00..218.75 rows=7375 width=70)
(10 rows)
activerecord_unittest=#
Thanks for the comment.
In my environment, it returns the primary key order as expected without order by but It does not look like deterministic since it does not Sort
at the end of the query.
Was thinking about adding order by a.attnum
but it just shows the column
order of the table, not the index key order.
create_table :countries_treaties, force: true, primary_key: [:country_id, :treaty_id] do |t|
t.string :country_id, null: false
t.string :treaty_id, null: false
end
- Without
ORDER BY i.idx
activerecord_unittest=# SELECT a.attname
FROM (
SELECT indrelid, indkey, generate_subscripts(indkey, 1) idx
FROM pg_index
WHERE indrelid = 'countries_treaties'::regclass
AND indisprimary
) i
JOIN pg_attribute a
ON a.attrelid = i.indrelid
AND a.attnum = i.indkey[i.idx];
attname
------------
country_id
treaty_id
(2 rows)
activerecord_unittest=# explain SELECT a.attname
activerecord_unittest-# FROM (
activerecord_unittest(# SELECT indrelid, indkey, generate_subscripts(indkey, 1) idx
activerecord_unittest(# FROM pg_index
activerecord_unittest(# WHERE indrelid = 'countries_treaties'::regclass
activerecord_unittest(# AND indisprimary
activerecord_unittest(# ) i
activerecord_unittest-# JOIN pg_attribute a
activerecord_unittest-# ON a.attrelid = i.indrelid
activerecord_unittest-# AND a.attnum = i.indkey[i.idx];
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------
Hash Join (cost=329.65..357.92 rows=43 width=64)
Hash Cond: ((pg_index.indrelid = a.attrelid) AND (pg_index.indkey[(generate_subscripts(pg_index.indkey, 1))] = a.attnum))
-> ProjectSet (cost=0.27..13.30 rows=1000 width=34)
-> Index Scan using pg_index_indrelid_index on pg_index (cost=0.27..8.29 rows=1 width=30)
Index Cond: (indrelid = '207561'::oid)
Filter: indisprimary
-> Hash (cost=218.75..218.75 rows=7375 width=70)
-> Seq Scan on pg_attribute a (cost=0.00..218.75 rows=7375 width=70)
(8 rows)
activerecord_unittest=#
- WITH
ORDER BY i.idx
activerecord_unittest=# explain SELECT a.attname
FROM (
SELECT indrelid, indkey, generate_subscripts(indkey, 1) idx
FROM pg_index
WHERE indrelid = 'countries_treaties'::regclass
AND indisprimary
) i
JOIN pg_attribute a
ON a.attrelid = i.indrelid
AND a.attnum = i.indkey[i.idx] ORDER BY i.idx;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------
Sort (cost=359.09..359.20 rows=43 width=68)
Sort Key: (generate_subscripts(pg_index.indkey, 1))
-> Hash Join (cost=329.65..357.92 rows=43 width=68)
Hash Cond: ((pg_index.indrelid = a.attrelid) AND (pg_index.indkey[(generate_subscripts(pg_index.indkey, 1))] = a.attnum))
-> ProjectSet (cost=0.27..13.30 rows=1000 width=34)
-> Index Scan using pg_index_indrelid_index on pg_index (cost=0.27..8.29 rows=1 width=30)
Index Cond: (indrelid = '207561'::oid)
Filter: indisprimary
-> Hash (cost=218.75..218.75 rows=7375 width=70)
-> Seq Scan on pg_attribute a (cost=0.00..218.75 rows=7375 width=70)
(10 rows)
activerecord_unittest=#
yahonda
Nov 25, 2018
Author
Contributor
Well, in the meantime I'm restoring this change to the current master one since it looks difficult (for me) to guarantee the order of index key, not table column order.
Well, in the meantime I'm restoring this change to the current master one since it looks difficult (for me) to guarantee the order of index key, not table column order.
Can also remove branch condition in rails/activerecord/test/cases/adapters/postgresql/connection_test.rb Lines 163 to 176 in d6fcc41 |
https://www.postgresql.org/support/versioning/ - 9.1 EOLed on September 2016. - 9.2 EOLed on September 2017. 9.3 is also not supported since Nov 8, 2018. https://www.postgresql.org/about/news/1905/ I think it may be a little bit early to drop PostgreSQL 9.3 yet. * Deprecated `supports_ranges?` since no other databases support range data type * Add `supports_materialized_views?` to abstract adapter Materialized views itself is supported by other databases, other connection adapters may support them * Remove `with_manual_interventions` It was only necessary for PostgreSQL 9.1 or earlier * Drop CI against PostgreSQL 9.2
Removed PostgreSQL version condition and |
rails 6 requires pg >= 9.3. ref: rails/rails#34520 Your version of PostgreSQL (90224) is too old. Active Record supports PostgreSQL >= 9.3. https://travis-ci.org/alexdean/persistent_hash/jobs/547384462
Summary
This pull request bumps the minimum version of PostgreSQL to 9.3, dropping PostgreSQL 9.1 and 9.2 support.
https://www.postgresql.org/support/versioning/
9.3 is also not supported since Nov 8, 2018. https://www.postgresql.org/about/news/1905/
I think it may be a little bit early to drop PostgreSQL 9.3 yet.
Here are other changes included in this pull request:
Deprecated
supports_ranges?
since no other databases support range data typeAdd
supports_materialized_views?
to abstract adapterMaterialized views itself is supported by other databases, other connection adapters may support them
Drop CI against PostgreSQL 9.2