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
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 |