| From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: postgres_fdw batching vs. (re)creating the tuple slots |
| Date: | 2021-06-04 11:52:28 |
| Message-ID: | 4e7ebff8-59ac-c90c-3ecd-8d9dfdfc75ad@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Argh! I forgot the attachments, of course.
On 6/4/21 1:48 PM, Tomas Vondra wrote:
> Hi,
>
> Here's two WIP patches that fixes the regression for me. The first part
> is from [1], so make large batches work, 0002 just creates a copy of the
> tupledesc to not cause issues in resource owner, 0003 ensures we only
> initialize the slots once (not per batch).
>
> With the patches applied, the timings look like this:
>
> batch timing
> ----------------------
> 1 64194.942 ms
> 10 7233.785 ms
> 100 2244.255 ms
> 32k 1372.175 ms
>
> which seems fine. I still need to get this properly tested etc. and make
> sure nothing is left over.
>
> regards
>
>
> [1]
> https://postgr.es/m/OS0PR01MB571603973C0AC2874AD6BF2594299%40OS0PR01MB5716.jpnprd01.prod.outlook.com
>
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Add-PQ_QUERY_PARAM_MAX_LIMIT.patch | text/x-patch | 4.9 KB |
| 0002-create-copy-of-a-descriptor-for-batching.patch | text/x-patch | 1.5 KB |
| 0003-initialize-slots-only-once-for-batching.patch | text/x-patch | 3.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Maxim Orlov | 2021-06-04 12:30:15 | Re: Parallel scan with SubTransGetTopmostTransaction assert coredump |
| Previous Message | Tomas Vondra | 2021-06-04 11:48:13 | Re: postgres_fdw batching vs. (re)creating the tuple slots |