Hi,
My personal feeling on this is, that the long time taken for the first query
is for loading all sorts of libraries, JVM startup overhead etc.
What if you first do some SELECT (whatever), on a different table, to warm
up the JVM and the database?
regards,
--Tim
THIS COMMUNICATION MAY
PC Drew wrote:
I tested this out and saw no improvement:
I'd still suspect some class loading issues and HotSpot compilation
issues are polluting your numbers.Try using a PreparedStatement to
another table first in order to make sure that classes bytecode has been
loaded. There are
Hello,
With the new preload option is there any benefit/drawback to using
pl/Python versus
pl/pgSQL? And no... I don't care that pl/Python is now considered untrusted.
Sincerely,
Joshua D. Drake
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support,
Hi,
with the following table:
Table public.foo
Column | Type | Modifiers
+--+---
t | text |
Indexes:
a btree (t)
Shouldn't queries that use
... where t like '%something%'
benefit from a when t is NULL in almost all cases, since the query
planner could use
My understanding is that having NULL values in an index breaks it completely. Meaning
it won't be used in any query planning. Maybe I'm wrong though...
-Original Message-
From: Marinos J. Yannikos [mailto:[EMAIL PROTECTED]
Sent: Tue 1/27/2004 12:26 PM
To: [EMAIL PROTECTED]
Cc:
