Re: [HACKERS] mdnblocks is an amazing time sink in huge relations
От | Vadim Mikheev |
---|---|
Тема | Re: [HACKERS] mdnblocks is an amazing time sink in huge relations |
Дата | |
Msg-id | 380D3B43.110ABE52@krs.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] mdnblocks is an amazing time sink in huge relations (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] mdnblocks is an amazing time sink in huge relations
Re: [HACKERS] mdnblocks is an amazing time sink in huge relations |
Список | pgsql-hackers |
Tom Lane wrote: > > I think the main problem is that relpages and reltuples shouldn't > be kept in pg_class columns at all, because they need to have > very different update behavior from the other pg_class columns. Yes, but is this reason to move them somewhere else? Let's update them differently (i.e. update in-place) but keep in pg_class. Should we provide read consistency for these internal-use columns? I'm not sure. > If we want to take reltuples seriously and try to maintain it > on-the-fly, then I think it needs still a third behavior. Clearly ...snip... I agreed that there is no way to get accurate estimation for # of rows to be seen by a query... Well, let's keep up-to-date # of rows present in relation: in any case a query will have to read them and this is what we need to estimate cost of simple scans, as for costs of joins - now way, currently(?) -:( But please remember that there is another SCC goal - faster catalog access... Vadim
В списке pgsql-hackers по дате отправления: