Conclusion... Comme dirais un certain rjuju, me citant...
rjuju a écrit :...
sqlpro a écrit :Bref, commencez par lire, apprendre, vous former à PostgreSQL...
Merci.
A +
Vous n'avez manifestement rien compris au problème.
]]>...
sqlpro a écrit :Bref, commencez par lire, apprendre, vous former à PostgreSQL...
Merci.
A +
]]>Merci. J'ai fait une bourde pour la CTE, il faut utiliser AS MATERIALIZED et non AS NOT MATERIALIZED. A vous de voir si c'est meilleur, mais à mon avis le ORDER BY supplémentaire sera meilleur.
Oui effectivement, ça le fait aussi :
dev_ds=> explain WITH w AS MATERIALIZED (
select uri, date from ds.document where extra->>'id_cellar' like '487d4f99-f65b-11ea-991b-01aa75ed71a1'
)
SELECT * FROM w LIMIT 1;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------
Limit (cost=189304.19..189304.21 rows=1 width=40)
CTE w
-> Bitmap Heap Scan on document (cost=3645.60..189304.19 rows=51760 width=50)
Recheck Cond: ((extra ->> 'id_cellar'::text) ~~ '487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
-> Bitmap Index Scan on ix_ds_document_id_cellar (cost=0.00..3632.66 rows=51760 width=0)
Index Cond: ((extra ->> 'id_cellar'::text) ~~ '487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
-> CTE Scan on w (cost=0.00..1035.20 rows=51760 width=40)
JIT:
Functions: 5
Options: Inlining false, Optimization false, Expressions true, Deforming true
(10 rows)
Time: 36.457 ms
Mais bon, le problème n'était pas d'être à 10 ms près, mais à un quart d'heure près :-D
]]>Merci du retour; Le coup du ORDER BY pour forcer Postgres à utiliser l'index semble faire mouche. Vous pouvez valider le temps d'exécution avec EXPLAIN (ANALYZE, BUFFERS).
Oui ça le fait avec le order by :
dev_ds=> SET enable_seqscan = on;
SET
Time: 0.331 ms
dev_ds=> EXPLAIN (ANALYZE, BUFFERS) select uri, date from ds.document where extra->>'id_cellar' like '487d4f99-f65b-11ea-991b-01aa75ed71a1' order by extra->>'id_cellar' limit 1;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=189692.39..189692.39 rows=1 width=82) (actual time=64.791..64.792 rows=1 loops=1)
Buffers: shared hit=9021
-> Sort (cost=189692.39..189821.79 rows=51760 width=82) (actual time=59.176..59.176 rows=1 loops=1)
Sort Key: ((extra ->> 'id_cellar'::text))
Sort Method: top-N heapsort Memory: 25kB
Buffers: shared hit=9021
-> Bitmap Heap Scan on document (cost=3645.60..189433.59 rows=51760 width=82) (actual time=59.160..59.166 rows=4 loops=1)
Recheck Cond: ((extra ->> 'id_cellar'::text) ~~ '487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
Heap Blocks: exact=4
Buffers: shared hit=9021
-> Bitmap Index Scan on ix_ds_document_id_cellar (cost=0.00..3632.66 rows=51760 width=0) (actual time=59.142..59.143 rows=4 loops=1)
Index Cond: ((extra ->> 'id_cellar'::text) ~~ '487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
Buffers: shared hit=9017
Planning Time: 0.143 ms
JIT:
Functions: 5
Options: Inlining false, Optimization false, Expressions true, Deforming true
Timing: Generation 0.803 ms, Inlining 0.000 ms, Optimization 0.385 ms, Emission 5.037 ms, Total 6.225 ms
Execution Time: 65.648 ms
(19 rows)
Time: 66.068 ms
dev_ds=>
Merci. Pouvez-vous essayer avec cette requête, en prenant soin de remettre enable_seqscan à on :
WITH w AS NOT MATERIALIZED ( explain select uri, date from ds.document where extra->>'id_cellar' like '487d4f99-f65b-11ea-991b-01aa75ed71a1' ) SELECT * FROM w LIMIT 1;
Vous tombez sur un des problèmes de l'optimiseur de PostgreSQL, où il "suppose" qu'il va trouver très rapidement une ligne qui colle au critère de filtrage.
Une idée, peut-être en l'air, serait de forcer un tri sur le résultat, là Postgres prend l'index pour retrouver la première ligne qui colle :
explain select uri, date from ds.document where extra->>'id_cellar' like '487d4f99-f65b-11ea-991b-01aa75ed71a1' order by extra->>'id_cellar' limit 1;
dev_ds=> explain WITH w AS NOT MATERIALIZED (
select uri, date from ds.document where extra->>'id_cellar' like '487d4f99-f65b-11ea-991b-01aa75ed71a1'
)
SELECT * FROM w LIMIT 1;
QUERY PLAN
-------------------------------------------------------------------------------------------------
Limit (cost=0.00..59.71 rows=1 width=50)
-> Seq Scan on document (cost=0.00..3090748.05 rows=51760 width=50)
Filter: ((extra ->> 'id_cellar'::text) ~~ '487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
(3 rows)
Time: 1.377 ms
dev_ds=>
dev_ds=> explain select uri, date from ds.document where extra->>'id_cellar' like '487d4f99-f65b-11ea-991b-01aa75ed71a1' order by extra->>'id_cellar' limit 1;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------
Limit (cost=189692.39..189692.39 rows=1 width=82)
-> Sort (cost=189692.39..189821.79 rows=51760 width=82)
Sort Key: ((extra ->> 'id_cellar'::text))
-> Bitmap Heap Scan on document (cost=3645.60..189433.59 rows=51760 width=82)
Recheck Cond: ((extra ->> 'id_cellar'::text) ~~ '487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
-> Bitmap Index Scan on ix_ds_document_id_cellar (cost=0.00..3632.66 rows=51760 width=0)
Index Cond: ((extra ->> 'id_cellar'::text) ~~ '487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
JIT:
Functions: 5
Options: Inlining false, Optimization false, Expressions true, Deforming true
(10 rows)
Time: 4.387 ms
Eventuellement, vous ne pouvez pas créer un btree pour voir ?
Non, ce sont les dernières heures auxquelles j'ai accès à la db.
Pour le fun, la différence entre les 2 :
dev_ds=> select uri, date from ds.document where extra->>'id_cellar' like '487d4f99-f65b-11ea-991b-01aa75ed71a1' limit 1;
uri | date
--------------------------------------+---------------------
******************************R_0007 | 2020-09-14 00:00:00
(1 row)
Time: 54.391 ms
dev_ds=> SET enable_seqscan = on;
SET
Time: 0.335 ms
dev_ds=> select uri, date from ds.document where extra->>'id_cellar' like '487d4f99-f65b-11ea-991b-01aa75ed71a1' limit 1;
uri | date
--------------------------------------+---------------------
******************************R_0007 | 2020-09-14 00:00:00
(1 row)
Time: 1064404.383 ms (17:44.404)
WITH w AS NOT MATERIALIZED (
explain select uri, date from ds.document where extra->>'id_cellar' like '487d4f99-f65b-11ea-991b-01aa75ed71a1'
)
SELECT * FROM w LIMIT 1;
Vous tombez sur un des problèmes de l'optimiseur de PostgreSQL, où il "suppose" qu'il va trouver très rapidement une ligne qui colle au critère de filtrage.
Une idée, peut-être en l'air, serait de forcer un tri sur le résultat, là Postgres prend l'index pour retrouver la première ligne qui colle :
explain select uri, date from ds.document where extra->>'id_cellar' like '487d4f99-f65b-11ea-991b-01aa75ed71a1' order by extra->>'id_cellar' limit 1;
Eventuellement, vous ne pouvez pas créer un btree pour voir ?
]]>Pour revenir au problème sur le LIMIT OFFSET 1comme l'a suggéré gleu, pouvez-vous redonner le plan d'exécution de la requête après avoir fait un SET enable_seqscan = off; dans la même session ?
dev_ds=> explain select uri, date from ds.document where extra->>'id_cellar' like '487d4f99-f65b-11ea-991b-01aa75ed71a1';
QUERY PLAN
-----------------------------------------------------------------------------------------------------
Bitmap Heap Scan on document (cost=3645.60..189304.19 rows=51760 width=50)
Recheck Cond: ((extra ->> 'id_cellar'::text) ~~ '487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
-> Bitmap Index Scan on ix_ds_document_id_cellar (cost=0.00..3632.66 rows=51760 width=0)
Index Cond: ((extra ->> 'id_cellar'::text) ~~ '487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
JIT:
Functions: 4
Options: Inlining false, Optimization false, Expressions true, Deforming true
(7 rows)
dev_ds=> explain select uri, date from ds.document where extra->>'id_cellar' like '487d4f99-f65b-11ea-991b-01aa75ed71a1' limit 1;
QUERY PLAN
-------------------------------------------------------------------------------------------------
Limit (cost=0.00..59.71 rows=1 width=50)
-> Seq Scan on document (cost=0.00..3090748.05 rows=51760 width=50)
Filter: ((extra ->> 'id_cellar'::text) ~~ '487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
(3 rows)
dev_ds=> explain select uri, date from ds.document where extra->>'id_cellar' like '%487d4f99-f65b-11ea-991b-01aa75ed71a1' limit 1;
QUERY PLAN
--------------------------------------------------------------------------------------------------
Limit (cost=0.00..2986.23 rows=1 width=50)
-> Seq Scan on document (cost=0.00..3090748.05 rows=1035 width=50)
Filter: ((extra ->> 'id_cellar'::text) ~~ '%487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
(3 rows)
dev_ds=> SET enable_seqscan = off;
SET
dev_ds=> explain select uri, date from ds.document where extra->>'id_cellar' like '487d4f99-f65b-11ea-991b-01aa75ed71a1';
QUERY PLAN
-----------------------------------------------------------------------------------------------------
Bitmap Heap Scan on document (cost=3645.60..189304.19 rows=51760 width=50)
Recheck Cond: ((extra ->> 'id_cellar'::text) ~~ '487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
-> Bitmap Index Scan on ix_ds_document_id_cellar (cost=0.00..3632.66 rows=51760 width=0)
Index Cond: ((extra ->> 'id_cellar'::text) ~~ '487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
JIT:
Functions: 4
Options: Inlining false, Optimization false, Expressions true, Deforming true
(7 rows)
dev_ds=> explain select uri, date from ds.document where extra->>'id_cellar' like '487d4f99-f65b-11ea-991b-01aa75ed71a1' limit 1;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------
Limit (cost=3645.60..3649.18 rows=1 width=50)
-> Bitmap Heap Scan on document (cost=3645.60..189304.19 rows=51760 width=50)
Recheck Cond: ((extra ->> 'id_cellar'::text) ~~ '487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
-> Bitmap Index Scan on ix_ds_document_id_cellar (cost=0.00..3632.66 rows=51760 width=0)
Index Cond: ((extra ->> 'id_cellar'::text) ~~ '487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
(5 rows)
dev_ds=> explain select uri, date from ds.document where extra->>'id_cellar' like '%487d4f99-f65b-11ea-991b-01aa75ed71a1' limit 1;
QUERY PLAN
------------------------------------------------------------------------------------------------------------
Limit (cost=3497.07..3501.03 rows=1 width=50)
-> Bitmap Heap Scan on document (cost=3497.07..7594.29 rows=1035 width=50)
Recheck Cond: ((extra ->> 'id_cellar'::text) ~~ '%487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
-> Bitmap Index Scan on ix_ds_document_id_cellar (cost=0.00..3496.81 rows=1035 width=0)
Index Cond: ((extra ->> 'id_cellar'::text) ~~ '%487d4f99-f65b-11ea-991b-01aa75ed71a1'::text)
(5 rows)
Time: 0.939 ms
Bref, commencez par lire, apprendre, vous former à PostgreSQL...
Merci.
]]>A +
]]>