On Fri, 31 Oct 2008, Gregory Stark wrote:
Tom Lane <[EMAIL PROTECTED]> writes:
Jeff Frost <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Huh. That does sound like it's a version-to-version difference.
There's nothing in the CVS log that seems related though. Are you
willing to post your test
Tom Lane <[EMAIL PROTECTED]> writes:
> Jeff Frost <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Huh. That does sound like it's a version-to-version difference.
>>> There's nothing in the CVS log that seems related though. Are you
>>> willing to post your test case?
>>>
>> It's a customer D
Jeff Frost <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Huh. That does sound like it's a version-to-version difference.
>> There's nothing in the CVS log that seems related though. Are you
>> willing to post your test case?
>>
> It's a customer DB, so I'll contact them and see if we can boil
Tom Lane wrote:
> Jeff Frost <[EMAIL PROTECTED]> writes:
>
>> On Thu, 30 Oct 2008, Tom Lane wrote:
>>
Any idea why I don't see it on 8.3.4?
>>> I think it's more likely some small difference in your test conditions
>>> than any real version-to-version difference. In pa
Jeff Frost <[EMAIL PROTECTED]> writes:
> On Thu, 30 Oct 2008, Tom Lane wrote:
>>> Any idea why I don't see it on 8.3.4?
>>
>> I think it's more likely some small difference in your test conditions
>> than any real version-to-version difference. In particular I think the
>> "still see" test might
On Thu, 30 Oct 2008, Tom Lane wrote:
Any idea why I don't see it on 8.3.4?
I think it's more likely some small difference in your test conditions
than any real version-to-version difference. In particular I think the
"still see" test might be influenced by the ages of transactions running
con
Jeff Frost <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Okay. What that means is that the indexes were created on data that had
>> already been inserted and updated to some extent, resulting in
>> HOT-update chains that turned out to be illegal for the new indexes.
>> The way we deal with this
Tom Lane wrote:
> Okay. What that means is that the indexes were created on data that had
> already been inserted and updated to some extent, resulting in
> HOT-update chains that turned out to be illegal for the new indexes.
> The way we deal with this is to mark the indexes as not usable by any
Jeff Frost <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This may be a HOT side-effect ... is pg_index.indcheckxmin set for
>> the index?
>>
> Yep, sure enough, the 'act' table's indexes have it set and jefftest and
> jefftest2's indexes do not.
Okay. What that means is that the indexes were
Tom Lane wrote:
> Jeff Frost <[EMAIL PROTECTED]> writes:
>
>> I've run across a strange problem with PG 8.3.3 not using indexes on a
>> particular table after building the table during a transaction.
>>
>
> This may be a HOT side-effect ... is pg_index.indcheckxmin set for
> the index?
>
Jeff Frost <[EMAIL PROTECTED]> writes:
> I've run across a strange problem with PG 8.3.3 not using indexes on a
> particular table after building the table during a transaction.
This may be a HOT side-effect ... is pg_index.indcheckxmin set for
the index?
regards, tom lane
I've run across a strange problem with PG 8.3.3 not using indexes on a
particular table after building the table during a transaction.
You can see a transcript of the issue here:
http://gist.github.com/21154
Interestingly, if I create another temp table 'CREATE TEMP TABLE AS
SELECT * FROM act' a
12 matches
Mail list logo
