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 wrote:
>
> On Fri, Feb 22, 2013 at 8:36 AM, jackrg
> wrote:
>
>> The following query produces a Recheck Cond and a costly Bitmap Heap Scan
>> even though I hav
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.
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
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
Alexander Staubo 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 of "creat
