Heikki Linnakangas writes:
> You can take the query, replace the ? parameter markers with $1, $2, and
> so forth, and explain it with psql like this:
> prepare foo (text) as select * from mytable where id = $1;
> explain analyze execute foo ('foo');
> On 9.2, though, this will explain the speci
On 22.02.2013 20:10, Markus Schulz wrote:
Am Freitag, 22. Februar 2013, 14:35:25 schrieb Heikki Linnakangas:
You could check what the generic plan looks like by taking the query
used in the java program, with the parameter markers, and running
EXPLAIN on that.
how can i do this?
I've tried the
Am Freitag, 22. Februar 2013, 14:35:25 schrieb Heikki Linnakangas:
> On 22.02.2013 10:25, Markus Schulz wrote:
> > i can run the query four times with good performance and after that
> > postgresql starts with the strange lseek() behavior.
>
> By default, the JDBC driver re-plans the prepared stat
Markus,
* Markus Schulz (m...@antzsystem.de) wrote:
> as you can see the query runs fine.
> I can run this query from a bash-psql-while-loop/jdbc-cli-tool
> endless without any problems.
> so far so good.
[...]
> JBoss EAP 5.1.2 with connection pooling and xa-datasource/two-phase-commits
> (tr
On 22.02.2013 10:25, Markus Schulz wrote:
i can run the query four times with good performance and after that postgresql
starts with the strange lseek() behavior.
By default, the JDBC driver re-plans the prepared statement for the
first 4 invocations of the query. On the fifth invocation, it s
hello,
i have a strange and reproducible bug with some select queries and 64bit
postgresql builds (works fine on 32bit builds).
The postgres process will run with 100% cpu-load (no io-wait) and strace
will show endless lseek(..., SEEK_END) calls on one table for minutes.
lseek(28, 0, SEEK_END)
