pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Andres Freund <andres@anarazel.de>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Macro customizable hashtable / bitmapscan & aggregation perf
Date: Mon, 10 Oct 2016 19:07:51 -0700
Message-ID: <20161011020751.o2ozug266i5vx7pt@alap3.anarazel.de> (raw)
In-Reply-To: <20161011004622.5kkvlwghm4yvg4id@alap3.anarazel.de>
References: <20160727004333.r3e2k2y6fvk2ntup@alap3.anarazel.de>
	<20161001004454.4wkqbmu67spvc3ak@alap3.anarazel.de>
	<41a178d4-a599-60e6-1657-e2489508858a@2ndquadrant.com>
	<20161001195956.u657cbvya7thzkr6@alap3.anarazel.de>
	<0b71d15b-89ef-bd4f-d653-0a118b550601@2ndquadrant.com>
	<20161002001758.GA14611@awork2>
	<ec2f8c1d-329b-e7b6-1406-f74af789c1f0@2ndquadrant.com>
	<20161009233803.6zjackpbz2v2s4sw@alap3.anarazel.de>
	<64bb428d-8e05-9130-5627-fac7e85a68aa@2ndquadrant.com>
	<20161011004622.5kkvlwghm4yvg4id@alap3.anarazel.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

On 2016-10-10 17:46:22 -0700, Andres Freund wrote:
> > TPC-DS (tpcds.ods)
> > ------------------
> > 
> > In this case, I'd say the results are less convincing. There are quite a few
> > queries that got slower by ~10%, which is well above - for example queries
> > 22 and 67. There are of course queries that got ~10% faster, and in total
> > the patched version executed more queries (so overall the result is slightly
> > positive, but not significantly).
> 
> That's interesting. I wonder whether that's plan changes just due to the
> changing memory estimates, or what's causing that. I'll look into it.

Hm. Based on an initial look those queries aren't planned with any of
the affected codepaths.  Could this primarily be a question of
randomness? Would it perhaps make sense to run the tests in a comparable
order? Looking at tpcds.py and the output files, it seems that the query
order differes between the runs, that can easily explain bigger
difference than the above. For me a scale=1 run creates a database of
approximately 4.5GB, thus with shared_buffers=1GB execution order is
likely to have a significant performance impact.

Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



view thread (23+ messages)  latest in thread

Message-ID: <20161011020751.o2ozug266i5vx7pt@alap3.anarazel.de>
Permalink:  ../20161011020751.o2ozug266i5vx7pt@alap3.anarazel.de/
Also on:    postgresql.org/message-id/20161011020751.o2ozug266i5vx7pt@alap3.anarazel.de

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: andres@anarazel.de, tomas.vondra@2ndquadrant.com
  Subject: Re: Macro customizable hashtable / bitmapscan & aggregation perf
  In-Reply-To: <20161011020751.o2ozug266i5vx7pt@alap3.anarazel.de>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox