Re: [HACKERS] mdnblocks is an amazing time sink in huge relations

From: Vadim Mikheev <vadim(at)krs(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] mdnblocks is an amazing time sink in huge relations
Date: 1999-10-20 03:47:16
Message-ID: 380D3B43.110ABE52@krs.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-10-20 03:57:44 Re: [HACKERS] mdnblocks is an amazing time sink in huge relations
Previous Message Vadim Mikheev 1999-10-20 02:34:02 Re: [HACKERS] Re: New developer globe