Re: [PATCH] Generic type subscription

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
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

In response to

Browse pgsql-hackers by date

  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?