Re: [PATCH] Generic type subscription - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: [PATCH] Generic type subscription
Date
Msg-id CA+q6zcW0uHyc89qDF=WaQXVraqw4Q3shoLvOBR+HjQbMw6=fzg@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Generic type subscription  (Artur Zakirov <a.zakirov@postgrespro.ru>)
List 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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Do we need use more meaningful variables to replace 0 in catalog head files?
Next
From: Pavel Stehule
Date:
Subject: Re: Tackling JsonPath support