Re: anti-join chosen even when slower than old plan - Mailing list pgsql-performance

From Vitalii Tymchyshyn
Subject Re: anti-join chosen even when slower than old plan
Date
Msg-id 4CDD1279.5090809@gmail.com
Whole thread Raw
In response to Re: anti-join chosen even when slower than old plan  (Cédric Villemain <cedric.villemain.debian@gmail.com>)
Responses Re: anti-join chosen even when slower than old plan  (Cédric Villemain <cedric.villemain.debian@gmail.com>)
List pgsql-performance
I'd say there are two Qs here:

1) Modify costs based on information on how much of the table is in
cache. It would be great  if this can be done, but I'd prefer to have it
as admin knobs (because of plan stability). May be both admin and
automatic ways can be followed with some parallel (disableable) process
modify knobs on admin behalf. In this case different strategies to
automatically modify knobs can be applied.

2) Modify costs for part of table retrieval. Then you need to define
"part". Current ways are partitioning and partial indexes. Some similar
to partial index thing may be created, that has only "where" clause and
no data. But has statistics and knobs (and may be personal bufferspace
if they are introduced). I don't like to gather data about "last X
percents" or like, because it works only in clustering and it's hard for
optimizer to decide if it will be enough to scan only this percents for
given query.

Best regards, Vitalii Tymchyshyn

pgsql-performance by date:

Previous
From: Cédric Villemain
Date:
Subject: Re: anti-join chosen even when slower than old plan
Next
From: Cédric Villemain
Date:
Subject: Re: anti-join chosen even when slower than old plan