| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Subject: | Re: Using JIT for VACUUM, COPY, ANALYZE |
| Date: | 2018-03-11 20:51:40 |
| Message-ID: | 20180311205140.wi3iby5xaseefkmu@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2018-03-11 12:38:54 -0700, Andres Freund wrote:
>
>
> On March 11, 2018 12:31:33 PM PDT, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> >Hi
> >
> >Today, these task can be CPU limited . Do you think, so JIT can be used
> >there too?
>
> Copy definitely, with the others I'm much more doubtful. Don't see anything around their bottlenecks that could be removed by JITing. Haven't looked at profiles of them recently however.
To expand a bit on that: JITing isn't magic - it needs to be able to
remove overhead to be beneficial. That can be removing very frequently
hit branches, indirect jumps and memory accesses. For e.g. expression
evaluation and tuple deforming it's not hard to see how that can be
done, yielding nice speedups. But for vacuuming where a lot of overhead
is in hot pruning and the like there's very little that can be removed.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2018-03-11 20:54:31 | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) |
| Previous Message | Peter Geoghegan | 2018-03-11 19:41:40 | Re: Parallel index creation does not properly cleanup after error |