Re: Bison state table

From: David Fetter <david(at)fetter(dot)org>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bison state table
Date: 2019-01-26 02:38:56
Message-ID: 20190126023856.GJ12076@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 25, 2019 at 06:55:56PM -0500, Bruce Momjian wrote:
> On Sat, Jan 26, 2019 at 12:49:50AM +0100, David Fetter wrote:
> > On Fri, Jan 25, 2019 at 05:38:59PM -0500, Bruce Momjian wrote:
> > > With our scanner keywords list now more cache-aware, and with us
> > > planning to use Bison for years to come, has anyone ever looked at
> > > reordering the bison state machine array to be more cache aware, e.g.,
> > > having common states next to each other rather than scattered around the
> > > array?
> >
> > Do we have a pretty good idea of what commonly grouped states are, or
> > at least a way to get some not-awful estimates of what they are?
>
> Uh, I am afraid we would need to profile the grammer with some sample
> queries and then base the reordering on that, kind of how compilers use
> sampling to do branch prediction. Yeah, crazy idea, I know. I figured
> some smart person might have written a tool to do that.

Since you're framing it that way, maybe there's something clever to do
with the llvm toolchain, which just happens to have facilities like
that. Perhaps smart people have already done this...

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-01-26 03:00:53 Re: using expression syntax for partition bounds
Previous Message Tom Lane 2019-01-26 02:17:10 Re: [PATCH] Allow UNLISTEN during recovery