Re: anti-join chosen even when slower than old plan
От | Andres Freund |
---|---|
Тема | Re: anti-join chosen even when slower than old plan |
Дата | |
Msg-id | 201011112111.05511.andres@anarazel.de обсуждение исходный текст |
Ответ на | Re: anti-join chosen even when slower than old plan (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
On Thursday 11 November 2010 19:58:49 Tom Lane wrote: > I wrote: > > I do think that something based around a settable-per-table caching > > percentage might be a reasonable way to proceed. > > BTW ... on reflection it seems that this would *not* solve the use-case > Kevin described at the start of this thread. What he's got AIUI is some > large tables whose recent entries are well-cached, and a lot of queries > that tend to hit that well-cached portion, plus a few queries that hit > the whole table and so see largely-not-cached behavior. We can't > represent that very well with a caching knob at the table level. Either > a high or a low setting will be wrong for one set of queries or the > other. > > It might work all right if he were to partition the table and then have > a different caching value attached to the currently-latest partition, > but that doesn't sound exactly maintenance-free either. Also, that only > works with the current statically-planned approach to partitioned > tables. I think where we're trying to go with partitioning is that > the planner doesn't consider the individual partitions, but the executor > just hits the right one at runtime --- so cost modifiers attached to > individual partitions aren't going to work in that environment. > > The most practical solution for his case still seems to be to twiddle > some GUC or other locally in the maintenance scripts that do the > full-table-scan queries. Unfortunately we don't have an equivalent > of per-session SET (much less SET LOCAL) for per-relation attributes. > Not sure if we want to go there. As dicussed in another thread some time ago another possibility is to probe how well the data i cached using mincore() or similar... While it presents problem with cache ramp-up it quite cool for other use-cases (like this one). Andre
В списке pgsql-performance по дате отправления: