Re: anti-join chosen even when slower than old plan

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