From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Viktor Leis <leis(at)in(dot)tum(dot)de> |
Cc: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Experimental evaluation of PostgreSQL's query optimizer |
Date: | 2015-12-23 19:43:59 |
Message-ID: | 567AF97F.3050603@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/21/15 7:49 PM, Craig Ringer wrote:
> CREATE JOIN STATISTICS ON t1 JOIN t2 USING (somecol);
>
>
> That way we let an admin who's tuning queries direct effort at problem
> areas. It's not automagical, but it's an area where tools could analyze
> pg_stat_statements to direct effort, much like is currently done for
> index creation. Like index creation I don't think it's practical to do
> this entirely automatically and behind the scenes since collecting the
> stats for all possibilities rapidly gets prohibitive.
There's an extremely common case that could (and IMO should) be
automated though, which is computing these statistics for all foreign
keys. We can have a way to disable that for specific keys if necessary,
but I'd bet it's extremely rare to have a FK that you never join on.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2015-12-23 19:50:06 | Re: Experimental evaluation of PostgreSQL's query optimizer |
Previous Message | Tom Lane | 2015-12-23 19:36:29 | Re: WIP: Fix parallel workers connection bug in pg_dump (Bug #13727) |