Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avaliar demora e consumo de dados da api de coberturas. #24

Open
0e1 opened this issue Jun 6, 2023 · 1 comment
Open

Avaliar demora e consumo de dados da api de coberturas. #24

0e1 opened this issue Jun 6, 2023 · 1 comment
Assignees

Comments

@0e1
Copy link
Collaborator

0e1 commented Jun 6, 2023

A api.jurisdiction_coverage vem consumindo muitos bytes e tempo na interface.

screen

@0e1 0e1 self-assigned this Jun 6, 2023
0e1 added a commit to osm-codes/WS that referenced this issue Jun 6, 2023
@0e1
Copy link
Collaborator Author

0e1 commented Jun 6, 2023

A alteração referencia acima reduziu o tempo que o BD leva para responder, como mostra o antes/depois a seguir.

EXPLAIN ANALYZE SELECT api.jurisdiction_coverage('BR-SP-Campinas');
                                     QUERY PLAN                                      
-------------------------------------------------------------------------------------
 Result  (cost=0.00..0.01 rows=1 width=32) (actual time=0.002..0.003 rows=1 loops=1)
 Planning Time: 108.595 ms
 Execution Time: 0.026 ms
(3 rows)




EXPLAIN ANALYZE SELECT api.jurisdiction_coverage('BR-SP-Campinas');
                                     QUERY PLAN                                      
-------------------------------------------------------------------------------------
 Result  (cost=0.00..0.01 rows=1 width=32) (actual time=0.001..0.001 rows=1 loops=1)
 Planning Time: 15.647 ms
 Execution Time: 0.008 ms
(3 rows)

No entanto, do lado do cliente ainda se obtem cerca de 1 segundo como tempo de resposta.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant