Re: [HACKERS] Improving executor performance - tidbitmap

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.

Re: [HACKERS] Improving executor performance - tidbitmap

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

Re: [HACKERS] Improving executor performance - tidbitmap

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

Re: [HACKERS] Improving executor performance - tidbitmap

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

Re: [HACKERS] Improving executor performance - tidbitmap

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

Re: [HACKERS] Improving executor performance - tidbitmap

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