Re: TODO idea - implicit constraints across child tables with a common column as primary key (but obviously not a shared index)

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Andrew Hammond" <andrew(dot)george(dot)hammond(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TODO idea - implicit constraints across child tables with a common column as primary key (but obviously not a shared index)
Date: 2007-04-24 13:22:41
Message-ID: 87d51toqji.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> The main data from the statistics that's of interest here are the extreme
>> values of the histogram. If we're not interested in any values in that range
>> then we can exclude the partition entirely.
>
> Except that there is *no* guarantee that the histogram includes the
> extreme values --- to promise that would require ANALYZE to scan every
> table row.

That's why I said:

a subsequent VACUUM ANALYZE could mark the resulting statistics as
"authoritative"

Not just plain analyze.

There's another issue here too. One of the other motivations is to be able to
put read-only tables on read-only media. To do that would require freezing
every tuple which would at the very least involve looking at every tuple. (It
would also involve waiting until all tuples are freezable too.)

So there's a natural step in which to gather these authoritative statistics
anyways.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2007-04-24 13:45:15 Re: [HACKERS] Wild idea: 9.0?
Previous Message Robert Treat 2007-04-24 13:18:54 Re: [HACKERS] Wild idea: 9.0?