Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > I've tried to avoid having the planner need to know the total size > of the database cluster, but it's kind of hard to avoid that if > you want to model this honestly. Agreed. Perhaps the cost could start escalating when the pages to access hit (effective_cache_size * relation_size / database_size), and escalate to the defaults (or some new GUCs) in a linear fashion until you hit effective_cache_size? > BTW, it seems that all these variants have an implicit assumption > that if you're reading a small part of the table it's probably > part of the working set I would say that the assumption should be that seq_page_cost and random_page_cost model the costs for less extreme (and presumably more common) queries, and that we're providing a way of handling the exceptional, extreme queries. -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
