From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: estimating # of distinct values |
Date: | 2011-01-18 00:56:35 |
Message-ID: | 8C0492A5-69F2-4F10-8D8C-DDF61E8C4429@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jan 17, 2011, at 6:36 PM, Tomas Vondra wrote:
> 1) Forks are 'per relation' but the distinct estimators are 'per
> column' (or 'per group of columns') so I'm not sure whether the file
> should contain all the estimators for the table, or if there should
> be one fork for each estimator. The former is a bit difficult to
> manage, the latter somehow breaks the current fork naming convention.
Yeah, when I looked at the fork stuff I was disappointed to find out there's essentially no support for dynamically adding forks. There's two other possible uses for that I can think of:
- Forks are very possibly a more efficient way to deal with TOAST than having separate tables. There's a fair amount of overhead we pay for the current setup.
- Dynamic forks would make it possible to do a column-store database, or at least something approximating one.
Without some research, there's no way to know if either of the above makes sense; but without dynamic forks we're pretty much dead in the water.
So I wonder what it would take to support dynamically adding forks...
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
From | Date | Subject | |
---|---|---|---|
Next Message | Dan Ports | 2011-01-18 01:00:28 | Re: SSI patch version 12 |
Previous Message | Jan Urbański | 2011-01-18 00:52:58 | Re: REVIEW: PL/Python validator function |