Re: WIP: Faster Expression Processing and Tuple Deforming (including JIT)

From: Nico Williams <nico(at)cryptonector(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Doug Doole <ddoole(at)salesforce(dot)com>
Subject: Re: WIP: Faster Expression Processing and Tuple Deforming (including JIT)
Date: 2016-12-06 20:35:43
Message-ID: 20161206203542.GD32541@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 06, 2016 at 12:27:51PM -0800, Andres Freund wrote:
> On 2016-12-06 14:19:21 -0600, Nico Williams wrote:
> > A bigger concern might be interface stability. IIRC the LLVM C/C++
> > interfaces are not very stable, but bitcode is.
>
> The C API is a lot more stable than the C++ bit, that's the primary
> reason I ended up using it, despite the C++ docs being better.

Ah.

> > > I concur with your feeling that hand-rolled JIT is right out. But
> >
> > Yeah, that way lies maintenance madness.
>
> I'm not quite that sure about that. I had a lot of fun doing some
> hand-rolled x86 JITing. Not that is a ward against me being mad. But
> more seriously: Manually doing a JIT gives you a lot faster compilation
> times, which makes JIT applicable in a lot more situations.

What I meant is that each time there are new ISA extensions, or
differences in how relevant/significant different implementations of the
same ISA implement certain instructions, and/or every time you want to
add a new architecture... someone has to do a lot of very low-level
work.

> > > I'm not sure that whatever performance gain we might get in this
> > > direction is worth the costs.
> >
> > Byte-/bit-coding query plans then JITting them is very likely to improve
> > performance significantly.
>
> Note that what I'm proposing is a far cry away from that - this converts
> two (peformance wise two, size wise one) significant subsystems, but far
> from all the executors to be JIT able. I think there's some more low

Yes, I know.

> hanging fruits (particularly aggregate transition functions), but
> converting everything seems to hit the wrong spot in the
> benefit/effort/maintainability triangle.

Maybe? At least with the infrastructure in place for it someone might
try it and see.

Nico
--

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-12-06 20:36:41 Re: WIP: Faster Expression Processing and Tuple Deforming (including JIT)
Previous Message Jeff Janes 2016-12-06 20:32:58 Re: Hash Indexes