Josh Berkus <josh@agliodbs.com> writes:
>> Also how will you handle column that are part of expressional indexes (where
>> foo is true for example) ?
> See my original proposal. These columns will be ignored. Expressions have
> their own stats.
Yeah, I see no particular need to increase the stats allocation for a
column merely because it is used in an expression index. The mechanism
Josh is proposing should cause the default amount of stats collected
*for the expression index* to go up, though.
BTW, there's an as-yet-undone bit of business associated with collecting
stats for expression indexes. The ANALYZE code will honor an explicit
attstattarget setting for an expressional index column, but there's no
clean way to get that setting into the system. What works in CVS tip is
regression=# create table foo (f1 int, f2 int);
CREATE TABLE
regression=# create index fooi on foo ((f1 + f2));
CREATE INDEX
regression=# alter table fooi alter column pg_expression_1 set statistics 100;
ALTER TABLE
but I don't much care for this; the arbitrary names that are used for
expressional columns shouldn't be embedded into SQL commands, and doing
"alter table" on an index looks a bit funny as well.
I want to make pg_dump dump these settings, but I'm not feeling
comfortable with having it dump commands that look like the above.
That would nail down the current method of assigning expression column
names as something we could never change without breaking dump scripts.
Can anyone think of a better way?
regards, tom lane
