Re: assertion failure 9.3.4 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: assertion failure 9.3.4
Date
Msg-id 18044.1397690384@sss.pgh.pa.us
Whole thread Raw
In response to Re: assertion failure 9.3.4  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: assertion failure 9.3.4  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> I'm not quite clear on why the third query, the one in ri_PerformCheck,
> is invoking a sequence.

It's not --- SeqNext is the next-tuple function for a sequential scan.
Nothing to do with sequences.

Now, it *is* worth wondering why the heck a query on the table's primary
key is using a seqscan and not an indexscan.  Maybe the planner thinks
there are just a few rows in the table?  But the stack trace seems
unexceptional other than that.

I'm wondering if the combination of autoexplain and pg_stat_statements
is causing trouble.

Yeah, it would be real nice to see a self-contained test case for this.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Misaligned BufferDescriptors causing major performance problems on AMD
Next
From: Peter Geoghegan
Date:
Subject: Re: Clock sweep not caching enough B-Tree leaf pages?