Adam Brusselback writes:
> I finally managed to get it compiled, patched, and working. It gave the
> same plan with the same estimates as when I turned fkey_estimates off.
OK, well, at least it's not making things worse ;-). But I think that
this estimation method isn't very helpful for antijoi
I finally managed to get it compiled, patched, and working. It gave the
same plan with the same estimates as when I turned fkey_estimates off.
I was wondering if I did things properly though, as i don't see the
enable_fkey_estimates GUC any more. Was it removed?
It'd be really hard to get a test dataset together I think, so I suppose
i'll learn how to compile Postgres. Will let you know how that goes.
Adam Brusselback writes:
> Alright with that off I get:
> ...
> Way better.
OK, that confirms the suspicion that beta1's FK-join-estimation logic
is the culprit here. We had already decided that that logic is broken,
and there's a rewrite in progress:
https://www.postgresql.org/message-id/15245.
Alright with that off I get:
'Nested Loop Anti Join (cost=25.76..21210.81 rows=16684 width=106) (actual
time=0.688..249.585 rows=26994 loops=1)'
' -> Hash Join (cost=25.34..7716.95 rows=21906 width=106) (actual
time=0.671..124.663 rows=28467 loops=1)'
'Hash Cond: (cp.claim_id = x.claim
Adam Brusselback writes:
> Gah, hit send too soon...
Hm, definitely a lot of foreign keys in there. Do the estimates get
better (or at least closer to 9.5) if you do
"set enable_fkey_estimates = off"?
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql
Gah, hit send too soon...
CREATE TEMPORARY TABLE _claims_to_process ( claim_id uuid, starting_state
enum.claim_state );
CREATE TABLE claim_product
(
claim_product_id uuid NOT NULL DEFAULT gen_random_uuid(),
claim_id uuid NOT NULL,
product_id uuid NOT NULL,
uom_type_id uuid NOT NULL,
reb
I analyzed all tables involved after loading, and also while trying to
diagnose this issue.
I have the same statistics target settings on both servers.
Here are the schemas for the tables:
On Thu, Jun 16, 2016 at 10:04 PM, Tom Lane wrote:
> Adam Brusselback writes:
> > Hey all, testing out 9.
Adam Brusselback writes:
> Hey all, testing out 9.6 beta 1 right now on Debian 8.5.
> I have a query that is much slower on 9.6 than 9.5.3.
The rowcount estimates in 9.6 seem way off. Did you ANALYZE the tables
after loading them into 9.6? Maybe you forgot some statistics target
settings?
If i
Hey all, testing out 9.6 beta 1 right now on Debian 8.5.
I have a query that is much slower on 9.6 than 9.5.3.
As a side note, when I explain analyze instead of just executing the query
it takes more than 2x as long to run. I have tried looking for info on that
online but have not found any. Any
10 matches
Mail list logo
