Search Postgresql Archives
pulling hair out trying to force replan
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: pgsql-general@xxxxxxxxxxxxxx
- Subject: pulling hair out trying to force replan
- From: Gene <genekhart@xxxxxxxxx>
- Date: Mon, 26 Feb 2007 00:05:06 -0500
- Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=PKMT56OatHS9KTyQTP8tElTKYibdbL2Kha2Q5H5+MJOsgbbVzTiEioJG9ndO3BWaqmnxR9erIWU+7xOke44vPQxHIb57TCNlante8qpP2aIRMpdL7C8ga9tvV/msNN1RETQBW6KnQJNcg4Kjog3hLsG4r+9/MbmSO+6uA1/m1h4=
- Reply-to: gene@xxxxxxxxx
I've got some pretty big tables with partial indexes on very specific values. It seems as though no matter what I try to force a replan it won't plan to use the partial indexes because it seems to be caching a plan valid for all potential parameters. I'm using hibernate which uses prepared statements over jdbc. I've tried setting prepareThreshold=0 to no avail.
PARTIAL INDEX ON varchar X with varchar_pattern_ops where X like '12345%'
LOG: duration: 9640.964 ms execute S_127/C_128: select ... from table this_ ... where this_.TIME>$1 and (1<>1 or ((1<>1 or this_.X like $2)))
DETAIL: parameters: $1 = '2007-02-02 04:56:38', $2 = '12345%'
If i take the query above and substitute manually the constants and do an explain it uses the partial indexes fine, and the query runs less than 10 ms...
Any suggestions would be most appreciated, I've been trying to solve this for a week now :(
Thanks,
Gene
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]
[Postgresql Jobs]
[Postgresql Admin]
[Postgresql Performance]
[Linux Clusters]
[PHP Home]
[PHP on Windows]
[Kernel Newbies]
[PHP Classes]
[PHP Books]
[PHP Databases]
[Postgresql & PHP]
[Yosemite]