From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com> |
Subject: | Re: Index trouble with 8.3b4 |
Date: | 2008-01-09 02:33:03 |
Message-ID: | 24770.1199845983@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Now an unindexed dead tuple is not a problem from vacuum's point of
>> view, nor does ANALYZE care, so AFAICS there is no need for this step
>> to wait for autovacuum processes --- nor indeed for manual vacuums.
> Also, ANALYZE was included in the latest security changes. Is there some way
> that ANALYZE could trigger some user-defined function being invoked which
> could in turn run some SQL using this index?
Hmm. ANALYZE itself doesn't look into the indexes, but it does invoke
user-defined functions that could nominally run queries. However, a
function in an index that runs a query that examines its own table seems
implausible, and very unlikely to work right anyway. You could hardly
expect such a function to be really immutable -- consider for example
that it would be unlikely to deliver the same results during CREATE
INDEX on an already-filled table that it would if the rows were being
inserted with the index already existing. So I'm not really worried
about that scenario.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-01-09 03:18:22 | Re: Index trouble with 8.3b4 |
Previous Message | Gregory Stark | 2008-01-09 02:31:17 | Re: Experiences with extensibility |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-01-09 03:18:22 | Re: Index trouble with 8.3b4 |
Previous Message | Gregory Stark | 2008-01-09 02:25:44 | Re: Named vs Unnamed Partitions |