You may be comparing the values to Tom's suggestion to bump up work_mem. Take a look at the original posting (Total runtime: 777208.041 ms for the bitmap scan) -Steve "Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote: On Thu, May 18, 2006 at 12:53:16PM -0700, Stephen By
06 at 12:38:18PM -0700, Stephen Byers wrote:> I repeated explain analyze on the query 5 times and it came up with the same plan.Yes, but did it end up with the same runtime? That's the interesting part --the plan will almost always be identical between explain analyze runs giventhat you haven&#x
I repeated explain analyze on the query 5 times and it came up with the same plan. You asked about index order and physical table order. In general the index order is indeed close to the same order as the physical table order. However, this query is likely an exception. The data is actually fro
"Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote: It sounds like PostgreSQL badly overestimates the cost of the index scan.Does the table perchance fit completely into memory, withouteffective_cache_size indicating that? Don't know the exact way to answer your question, but my initial instinct is
Could someone explain the results of the following? This is with postgres 8.1.2 on a database that was just vacuum-verbose-analyzed. I have packets_i4 index which I am expecting to be used with this query but as you can see, I have have to convince its usage by turning off other scans. The total
