Josh Berkus <[EMAIL PROTECTED]> writes:
> To sum up the below: it appears that whenever a set of WHERE conditions
> exceeds a certain level of complexity, the planner just ignores all
> applicable indexes and goes for a seq scan.
It looks to me like the planner is coercing the WHERE clause into
Tom,
I've found the problem with TPC-R query #19. And it, unfortunately, appears
to be a problem in the PostgreSQL query planner.
To sum up the below: it appears that whenever a set of WHERE conditions
exceeds a certain level of complexity, the planner just ignores all
applicable indexes and
On Thu, 2003-09-25 at 14:32, Jenny Zhang wrote:
> I am running TPC-H with scale factor of 1 on RedHat7.2 with the kernel
> 2.5.74. Q17 can always finish in about 7 seconds on my system. The
> execution plan is:
I just want to point out that we are the OSDL are not running
a TPC-X anything. W
On Tue, 7 Oct 2003, Stef wrote:
> The initial instance took up 8372K and this fluctuated
> between +- 8372K and 10372K, plus +- 3500K for
> every connection.
>
Does that include/exlude the size of say, shared code & libraries?
I know linux does copy-on-write forking.. so it may be less in realit
Hi again all,
I've tested postgres 7.3.4 on Linux version 2.4.17
and this is what I found :
The initial instance took up 8372K and this fluctuated
between +- 8372K and 10372K, plus +- 3500K for
every connection.
I did quite a few transactions on both connections, plus
a few vacuums and a pg_du
