Received: from localhost (maia-1.hub.org [200.46.204.191])
	by postgresql.org (Postfix) with ESMTP id 6F6C09FB8EB
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Thu, 12 Apr 2007 19:22:55 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024)
	with ESMTP id 38847-01 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Thu, 12 Apr 2007 19:22:52 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id 2366D9FB86F
	for <pgsql-performance@postgresql.org>;
	Thu, 12 Apr 2007 19:22:52 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id l3CMMofK009458;
	Thu, 12 Apr 2007 18:22:50 -0400 (EDT)
To: Steve <cheetah@tanabi.org>
cc: PostgreSQL Performance <pgsql-performance@postgresql.org>
Subject: Re: Strangely Variable Query Performance 
In-reply-to: <Pine.GSO.4.64.0704121757060.17955@kittyhawk.tanabi.org> 
References: <57271CC2-BCB1-4ACA-A177-4FF64F1BC33F@brandeis.edu>
	<E1HbzJr-0005VG-GC@elasmtp-curtail.atl.sa.earthlink.net>
	<16E9A17C-ADFA-43B2-B7EA-5C7A4D7E96D1@event-s.net>
	<E1Hc0lc-0001iE-La@elasmtp-banded.atl.sa.earthlink.net>
	<0914C05F-BA1B-4A6C-A1B1-52256BC851A4@event-s.net>
	<1176396964.13754.16.camel@state.g2switchworks.com>
	<Pine.LNX.4.64.0704121000570.32187@glacier.frostconsultingllc.com>
	<Pine.GSO.4.64.0704121653030.17955@kittyhawk.tanabi.org>
	<5772.1176413092@sss.pgh.pa.us>
	<Pine.GSO.4.64.0704121735000.17955@kittyhawk.tanabi.org>
	<9213.1176415301@sss.pgh.pa.us>
	<Pine.GSO.4.64.0704121757060.17955@kittyhawk.tanabi.org>
Comments: In-reply-to Steve <cheetah@tanabi.org>
	message dated "Thu, 12 Apr 2007 18:03:47 -0400"
Date: Thu, 12 Apr 2007 18:22:49 -0400
Message-ID: <9457.1176416569@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200704/271
X-Sequence-Number: 24148

Steve <cheetah@tanabi.org> writes:
> Datum   ddd_text_revcmp(PG_FUNCTION_ARGS){
>          char*           arg1=(char*)VARDATA(PG_GETARG_TEXT_P(0));
>          char*           arg2=(char*)VARDATA(PG_GETARG_TEXT_P(1));

>          if((*arg1) != (*arg2)){
>                  PG_RETURN_INT32(*arg2 - *arg1);
>          }else{
>                  PG_RETURN_INT32(strcmp(arg2,arg1));
>          }
> }

[ itch... ]  That code is just completely wrong, because the contents
of a TEXT datum aren't guaranteed null-terminated.  It'd be better to
invoke bttextcmp and negate its result.

That's not relevant to your immediate problem, but if you've noticed
any strange behavior with your text_revop indexes, that's the reason...

			regards, tom lane