Simon Riggs wrote:
> On Mon, 2007-10-15 at 22:54 +0100, Dave Page wrote:
>
>> A change has been applied for GP compatibility. It will be in pgAdmin 1.8.
>
> Wow Dave, that was quick! It was the right place after all. :-)
>
I exchanged a couple of emails with Luke a day or two back :-)
/D
On Mon, 2007-10-15 at 22:54 +0100, Dave Page wrote:
> A change has been applied for GP compatibility. It will be in pgAdmin 1.8.
Wow Dave, that was quick! It was the right place after all. :-)
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of broadc
> --- Original Message ---
> From: Simon Riggs <[EMAIL PROTECTED]>
> To: "Roberts, Jon" <[EMAIL PROTECTED]>
> Sent: 15/10/07, 21:19:04
> Subject: Re: [BUGS] BUG #3667: Job scheduling with Greenplum fails
>
> On Thu, 2007-10-11 at 10:42 -0500
On Thu, 2007-10-11 at 10:42 -0500, Roberts, Jon wrote:
> Like I said in the email, I think the best solution is to put the code in a
> function. However, after I inserted a total of 25 jobs, the difference is
> more noticeable and my sql is better in terms of cost and total time.
You're missing
6..0.006 rows=0 loops=2)"
"Index Cond: (ag.jagpid = j.jobagentid)"
"-> Index Scan using pga_jobclass_pkey on pga_jobclass cl
(cost=0.00..0.75 rows=1 width=22) (actual time=0.016..0.020 rows=1 loops=2)"
" Index Cond: (cl.jclid
On Thu, Oct 11, 2007 at 07:31:44AM -0500, Roberts, Jon wrote:
> The cost is significantly lower but the total runtime is higher.
Um, so you want developers to change the thing so that it performs
more slowly, but has a prettier estimate of how much work it's going
to do? That seems like a poor
Another solution would be to call a function in the database rather than
imbedding the SQL in C++. If you look at pgagent.sql, there are a few
functions created to support jobs. Maybe this could be another function
call so it could easily be modified to support Greenplum and make it easier
for users
Index Cond: (ag.jagpid = j.jobagentid)"
"-> Index Scan using pga_jobclass_pkey on pga_jobclass cl
(cost=0.00..0.37 rows=1 width=36)"
" Index Cond: (cl.jclid = j.jobjclid)"
Surely the cost dropping from 5359 to 81 is worth the trouble.
Jon
-O
"Roberts, Jon" <[EMAIL PROTECTED]> writes:
> What if the new query has a significantly lower cost compared to the older
> one?
Much as I'd like the planner to be infallible, it ain't; estimated costs
are no proof of any real-world performance difference. Better show
EXPLAIN ANALYZE numbers if you
"Jon Roberts" <[EMAIL PROTECTED]> writes:
> Greenplum doesn't support "correlated subqueries" which PGAdmin III uses
> when PgAgent is installed.
Surely this complaint should be directed to Greenplum. Correlated
subqueries are a required entry-level feature in the SQL92 standard,
and have been
The following bug has been logged online:
Bug reference: 3667
Logged by: Jon Roberts
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2
Operating system: Solaris
Description:Job scheduling with Greenplum fails
Details:
Greenplum doesn't support "correlated sub
11 matches
Mail list logo
