Hi,
On 2016-11-04 15:25:58 -0700, Doug Doole wrote:
> On 07/13/2016 06:18 PM, Andres Freund wrote:
> > Attached (in patch 0003) is a proof-of-concept implementing an
> > expression evalution framework that doesn't use recursion. Instead
> > ExecInitExpr2 computes a number of 'steps' necessary to c
Attached (in patch 0003) is a proof-of-concept implementing an
expression evalution framework that doesn't use recursion. Instead
ExecInitExpr2 computes a number of 'steps' necessary to compute an
expression. These steps are stored in a linear array, and executed one
after another (save boolean ex
On 07/13/2016 06:18 PM, Andres Freund wrote:
Attached (in patch 0003) is a proof-of-concept implementing an
expression evalution framework that doesn't use recursion. Instead
ExecInitExpr2 computes a number of 'steps' necessary to compute an
expression. These steps are stored in a linear array, a
On Wed, Jul 13, 2016 at 6:18 PM, Andres Freund wrote:
> While, as in 6) above, removing linked lists from the relevant
> structures helps, it's not that much. Staring at this for a long while
> made me realize that, somewhat surprisingly to me, is that one of the
> major problems is that we are bo
On 2016-07-17 08:32:17 -0400, Robert Haas wrote:
> On Wed, Jul 13, 2016 at 11:06 PM, Andres Freund wrote:
> > The major issue with the simplehash implementation in the path is
> > probably the deletion; which should rather move cells around, rather
> > than use toombstones. But that was too comple
On Wed, Jul 13, 2016 at 11:06 PM, Andres Freund wrote:
> On 2016-06-24 16:29:53 -0700, Andres Freund wrote:
>> 4) Various missing micro optimizations have to be performed, for more
>>architectural issues to become visible. E.g. [2] causes such bad
>>slowdowns in hash-agg workloads, that ot
On Thu, Jul 14, 2016 at 8:45 PM, Andres Freund wrote:
> Brin indexes IIRC always end up using tidbitmap.c, so the benefits
> should be there as well ;)
Right. Might the improvement be even more pronounced, though?
I'm not sure how a BRIN index with a suitable physical/logical
correlation perform
On 2016-07-14 20:41:21 -0700, Peter Geoghegan wrote:
> On Wed, Jul 13, 2016 at 8:06 PM, Andres Freund wrote:
> > I've quickly hacked up an alternative linear addressing hashtable
> > implementation. And the improvements are quite remarkable.
> >
> > Example Query:
> > EXPLAIN ANALYZE SELECT SUM(l_
On Wed, Jul 13, 2016 at 8:06 PM, Andres Freund wrote:
> I've quickly hacked up an alternative linear addressing hashtable
> implementation. And the improvements are quite remarkable.
>
> Example Query:
> EXPLAIN ANALYZE SELECT SUM(l_extendedprice) FROM lineitem WHERE (l_shipdate
> >= '1995-01-01'
Andres Freund writes:
> On 2016-07-14 23:03:10 +0200, Andreas Seltenreich wrote:
>> That's the plan, yes. I'm sorry there's no publishable code yet on the
>> the postgres side of things. Using libFirm[1], the plan is to.
>
> Why libfirm?
- It has a more modern IR than LLVM (they're catching up
On 2016-07-14 23:03:10 +0200, Andreas Seltenreich wrote:
> That's the plan, yes. I'm sorry there's no publishable code yet on the
> the postgres side of things. Using libFirm[1], the plan is to.
Why libfirm? It seems to only have x86 and sparc backends, and no
windows support?
> 1. Automatical
Andres Freund writes:
> The problem is that the previous form has a lot of ad-hoc analysis
> strewn in. The interesting part is getting rid of all that. That's what
> the new ExecInitExpr2() does. The target form can be both evaluated more
> efficiently in the dispatch manner in the patch, and qui
On 2016-07-14 20:04:03 +0200, Andreas Seltenreich wrote:
> Andres Freund writes:
>
> > Having expression evaluation and slot deforming as a series of simple
> > sequential steps, instead of complex recursive calls, would also make it
> > fairly straightforward to optionally just-in-time compile th
Andres Freund writes:
> Having expression evaluation and slot deforming as a series of simple
> sequential steps, instead of complex recursive calls, would also make it
> fairly straightforward to optionally just-in-time compile those.
I don't think that JIT becomes easier by this change. Constr
Hi,
On 2016-06-24 16:29:53 -0700, Andres Freund wrote:
> 4) Various missing micro optimizations have to be performed, for more
>architectural issues to become visible. E.g. [2] causes such bad
>slowdowns in hash-agg workloads, that other bottlenecks are hidden.
One such issue is the usage
Hi,
On 2016-06-24 16:29:53 -0700, Andres Freund wrote:
> 2) Baring 1) tuple deforming is the biggest bottleneck in nearly all
>queries I looked at. There's various places we trigger deforming,
>most ending in either slot_deform_tuple(), heap_getattr(),
>heap_deform_tuple().
>
>This
On 30 June 2016 at 02:32, Andres Freund wrote:
>
> Hi,
>
> On 2016-06-28 10:01:28 +, Rajeev rastogi wrote:
> > >3) Our 1-by-1 tuple flow in the executor has two major issues:
> >
> > Agreed, In order to tackle this IMHO, we should
> > 1. Makes the processing data-centric instead of operator c
Hi,
On 2016-06-28 10:01:28 +, Rajeev rastogi wrote:
> >3) Our 1-by-1 tuple flow in the executor has two major issues:
>
> Agreed, In order to tackle this IMHO, we should
> 1. Makes the processing data-centric instead of operator centric.
> 2. Instead of pulling each tuple from immediate oper
On 25 June 2016 05:00, Andres Freund Wrote:
>To: pgsql-hackers@postgresql.org
>Subject: [HACKERS] Improving executor performance
>
>My observations about the performance bottlenecks I found, and partially
>addressed, are in rough order of importance (there's interdependence
>between most of them):
On Fri, Jun 24, 2016 at 05:25:27PM -0700, Peter Geoghegan wrote:
> On Fri, Jun 24, 2016 at 4:29 PM, Andres Freund wrote:
> > As a motivation, here's a somewhat juicy example of the benefits that
> > can be gained (disabled parallelism, results vary too much):
> > SELECT l_linestatus, SUM(l_quantit
On Fri, Jun 24, 2016 at 4:29 PM, Andres Freund wrote:
> As a motivation, here's a somewhat juicy example of the benefits that
> can be gained (disabled parallelism, results vary too much):
> SELECT l_linestatus, SUM(l_quantity) FROM lineitem GROUP BY 1 ORDER BY 2 DESC
> LIMIT 10 ;
> non-optimized
Hi,
On 2016-06-24 16:29:53 -0700, Andres Freund wrote:
> Comments so far? Different suggestions on how to get improvements
> around this merged?
Oh, and if somebody is interested on collaborating on some of
these... This is far too big for me to tackle alone.
Andres
--
Sent via pgsql-hacker
22 matches
Mail list logo
