On Wed, 10 Nov 2004 14:51:57 +0100, Michael Kleiser [EMAIL PROTECTED] wrote:
Statement st = con.createStatement();
java.sql.Timestamp datum = new java.sql.Timestamp(new
Date().getTime());
Date start = new Date();
Jim C. Nasby wrote:
I'm wondering if there's any way I can tweak things so that the estimate
for the query is more accurate (I have run analyze):
Can you post your configuration file ? I'd like to see for example your
settings about: random_page_cost and effective_cache_size.
Regards
Gaetano
On Thu, Nov 11, 2004 at 04:04:06PM +0800, Edwin Eyan Moragas wrote:
how about using PreparedStatment? that's on the java end.
on the pg end, maybe do a BEGIN before the for loop and
END at the end of the for loop.
You don't even need a BEGIN and END; his code has a setAutoComit(true)
before
patrick ~ wrote:
--- John Meinel [EMAIL PROTECTED] wrote:
If you are trying to establish existence, we also had a whole thread on
this. Basically what we found was that adding an ORDER BY clause, helped
tremendously in getting the planner to switch to an Index scan. You
might try something
Ok, you thought maybe this thread died or got abandoned in the face of
all the senseless trolling and spam going on.. you were wrong.. ;)
I thought though I'd start over trying to explain what's going on.
I've gone through some dumps, and recreation of the database with some
different filesystem
Allen,
Ok, you thought maybe this thread died or got abandoned in the face of
all the senseless trolling and spam going on.. you were wrong.. ;)
I thought though I'd start over trying to explain what's going on.
I've gone through some dumps, and recreation of the database with some
On Thu, 11 Nov 2004 10:52:43 -0800, Josh Berkus [EMAIL PROTECTED] wrote:
Allen,
Ok, you thought maybe this thread died or got abandoned in the face of
all the senseless trolling and spam going on.. you were wrong.. ;)
I thought though I'd start over trying to explain what's going on.
Allen Landsidel [EMAIL PROTECTED] writes:
QUERY PLAN
---
Index Scan using sname_unique on testtable (cost=0.00..34453.74
rows=8620 width=20) (actual
On Thu, 11 Nov 2004 11:04:18 +0100, Steinar H. Gunderson
[EMAIL PROTECTED] wrote:
You don't even need a BEGIN and END; his code has a setAutoComit(true)
before the for loop, which just has to be changed to setAutoCommit(false)
(and add an explicit commit() after the for loop, of course).
amen.
On 11 Nov 2004 15:49:46 -0500, Greg Stark [EMAIL PROTECTED] wrote:
Allen Landsidel [EMAIL PROTECTED] writes:
QUERY PLAN
---
Index Scan using
Allen Landsidel [EMAIL PROTECTED] writes:
Clustering is really unworkable in this situation.
Nonetheless, please do it in your test scenario, so we can see if it has
any effect or not.
The speed you're getting works out to about 7.2 msec/row, which would be
about right if every single row fetch
---
Index Scan using sname_unique on testtable (cost=0.00..34453.74
rows=8620 width=20) (actual time=77.004..537065.079 rows=74612
loops=1)
Index Cond:
12 matches
Mail list logo
