Josh Berkus <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend