Re: Index trouble with 8.3b4

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

In response to

Browse pgsql-general by date

  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

Browse pgsql-hackers by date

  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