Alexander Staubo a...@bengler.no writes:
That's right. So I created a composite index, and not only does this make the
plan correct, but the planner now chooses a much more efficient plan than the
previous index that indexed only on conversation_id:
...
Is this because it can get the value
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
Heikki Linnakangas hlinnakan...@vmware.com 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
On Friday, February 22, 2013, Carlo Stonebanks wrote:
Hi Jeff, thanks for the reply.
** **
** **
What is going on during the interregnum? Whatever it is, it seems to be
driving the log_2013_01_session_idx index out of the cache, but not the
log_2013_01 table. (Or perhaps the table
On Friday, February 22, 2013, Carlo Stonebanks wrote:
My understanding of PG’s cluster is that this is a one-time command that
creates a re-ordered table and doesn’t maintain the clustered order until
the command is issued again. During the CLUSTER, the table is read and
write locked. So,
On Fri, Feb 22, 2013 at 9:45 AM, Jack Royal-Gordon
j...@groundbreakingsoftware.com wrote:
On Feb 22, 2013, at 9:19 AM, Jeff Janes jeff.ja...@gmail.com wrote:
On Fri, Feb 22, 2013 at 8:36 AM, jackrg
j...@groundbreakingsoftware.comwrote:
The following query produces a Recheck Cond and a
