Re: Default Stats Revisited

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: josh(at)agliodbs(dot)com
Cc: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Default Stats Revisited
Date: 2004-03-11 23:36:19
Message-ID: 2837.1079048179@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-03-12 00:01:47 Re: [HACKERS] The Name Game: postgresql.net vs. pgfoundry.org
Previous Message Jeroen T. Vermeulen 2004-03-11 23:24:20 Re: [HACKERS] The Name Game: postgresql.net vs. pgfoundry.org