From: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
---|---|
To: | Artur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru> |
Cc: | Victor Wagner <vitus(at)wagner(dot)pp(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Generic type subscription |
Date: | 2016-11-13 17:52:00 |
Message-ID: | CA+q6zcW0uHyc89qDF=WaQXVraqw4Q3shoLvOBR+HjQbMw6=fzg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi
Sorry for late reply and thank you for the feedback (especially about the
problem with performance).
> There is another occurrences of "subscription" including file names
Fixed.
> we have performance degradation of SELECT queries
Yes, I figured it out. The main problem was about type info lookups, some of
them were made for each data extraction operation, which is unnecessary.
Here are results on my machine:
with the fixed version of patch
=# explain analyze select a[1], b[1][1][1] from test;
QUERY PLAN
------------------------------------------------------------------------------------------------------------
Seq Scan on test (cost=0.00..5286.00 rows=100000 width=6) (actual
time=0.950..48.370 rows=100000 loops=1)
Planning time: 0.054 ms
Execution time: 51.859 ms
(3 rows)
and without the patch
=# explain analyze select a[1], b[1][1][1] from test;
QUERY PLAN
------------------------------------------------------------------------------------------------------------
Seq Scan on test (cost=0.00..5286.00 rows=100000 width=6) (actual
time=3.443..43.452 rows=100000 loops=1)
Planning time: 0.117 ms
Execution time: 46.875 ms
(3 rows)
It's still slightly slower because of all new logic aroung subscripting
operation, but not that much.
Attachment | Content-Type | Size |
---|---|---|
generic_type_subscription_v4.patch | text/x-patch | 205.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2016-11-13 18:26:00 | Re: Tackling JsonPath support |
Previous Message | Tom Lane | 2016-11-13 17:19:50 | Re: Do we need use more meaningful variables to replace 0 in catalog head files? |