Re: [PERFORM] Extremely irregular query performance

2006-01-13 Thread Kenneth Marshall
On Thu, Jan 12, 2006 at 03:23:14PM -0500, Jean-Philippe Cote wrote: > > > Can I actully know whether a given plan is excuted with GEQO on ? > In other words, if I launch 'explain ', I'll get a given plan, but if > I re-launch > the (withtout the 'explain' keyword), could I get a different > pla

Re: [PERFORM] Extremely irregular query performance

2006-01-13 Thread Kenneth Marshall
On Thu, Jan 12, 2006 at 09:48:41AM +, Simon Riggs wrote: > On Wed, 2006-01-11 at 22:23 -0500, Tom Lane wrote: > > =?iso-8859-1?Q?Jean-Philippe_C=F4t=E9?= <[EMAIL PROTECTED]> writes: > > > Thanks a lot for this info, I was indeed exceeding the genetic > > > optimizer's threshold. Now that it is

[PERFORM] Postgres8.0 Planner chooses WRONG plan.

2006-01-13 Thread Pallav Kalva
Hi , I am having problem optimizing this query, Postgres optimizer uses a plan which invloves seq-scan on a table. And when I choose a option to disable seq-scan it uses index-scan and obviously the query is much faster. All tables are daily vacummed and analyzed as per docs. Why can

[PERFORM] Extremely irregular query performance

2006-01-13 Thread Jean-Philippe Côté
Hi, I'm running version 8.1 on a dedicated Sun v20 server (2 AMD x64's) with 4Gb of RAM. I have recently noticed that the performance of some more complex queries is extremely variable and irregular. For example, I currently have a query that returns a small number of rows (5) by joining a dozen

[PERFORM] >= forces row compare and not index elements compare when possible

2006-01-13 Thread Bernard Dhooghe
Suppose a table with structure: Table "public.t4" Column | Type | Modifiers +---+--- c1 | character(10) | not null c2 | character(6) | not null c3 | date | not null c4 | character(30) | c5 | numeric(10,2) | not null Indexes:

[PERFORM] Hanging Query

2006-01-13 Thread vimal . gupta
We have to inserts a records(15000- 2) into a table which also contains (15000-2) records, then after insertion, we have to delete the records according to a business rule. Above process is taking place in a transaction and we are using batches of 128 to insert records. Everything works fi

Re: [PERFORM] Extremely irregular query performance

2006-01-13 Thread Bruce Momjian
Jean-Philippe Cote wrote: > > > Can I actully know whether a given plan is excuted with GEQO on ? > In other words, if I launch 'explain ', I'll get a given plan, but if > I re-launch > the (withtout the 'explain' keyword), could I get a different > plan given that GEQO induces some randomness

Re: [PERFORM] Stable function being evaluated more than once in a single query

2006-01-13 Thread Jim C. Nasby
Adding -docs... On Fri, Jan 13, 2006 at 07:27:28PM -0500, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > Is the issue that the optimizer won't combine two function calls (ie: > > SELECT foo(..) ... WHERE foo(..)), or is it that sometimes it won't make > > the optimization (maybe

Re: [PERFORM] Stable function being evaluated more than once in a single query

2006-01-13 Thread Tom Lane
"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > Is the issue that the optimizer won't combine two function calls (ie: > SELECT foo(..) ... WHERE foo(..)), or is it that sometimes it won't make > the optimization (maybe depending on the query plan, for example)? What the STABLE category actually does

Re: [PERFORM] Throwing unnecessary joins away

2006-01-13 Thread Jim C. Nasby
On Thu, Jan 12, 2006 at 07:51:22PM +0100, Ott? Havasv?lgyi wrote: > Hi, > > If the join is to a primary key or notnull unique column(s), then > inner join is also ok. But of course left join is the simpler case. > An example: Actually, you need both the unique/pk constraint, and RI (a fact I miss

Re: [PERFORM] Throwing unnecessary joins away

2006-01-13 Thread Jim C. Nasby
On Thu, Jan 12, 2006 at 01:35:07PM +0100, Alessandro Baretta wrote: > Ott? Havasv?lgyi wrote: > >Hi all, > > > >Is PostgreSQL able to throw unnecessary joins? > >For example I have two tables, and I join then with their primary keys, > >say type of bigint . In this case if I don't reference to on

Re: [PERFORM] Stable function being evaluated more than once in a single query

2006-01-13 Thread Jim C. Nasby
On Wed, Jan 11, 2006 at 11:33:23PM -0500, Tom Lane wrote: > Mark Liberman <[EMAIL PROTECTED]> writes: > > I've got a set-returning function, defined as STABLE, that I reference > > twice > > within a single query, yet appears to be evaluated via two seperate > > function > > scans. > > There i

Re: [PERFORM] Slow query with joins

2006-01-13 Thread Jim C. Nasby
On Wed, Jan 11, 2006 at 10:30:58PM +0100, Bendik Rognlien Johansen wrote: > The sort is definitively the culprit. When I removed it the query was > instant. I tried setting work_mem = 131072 but it did not seem to > help. I really don't understand this :-( Any other ideas? What's explain analy

Re: [PERFORM] insert without oids

2006-01-13 Thread Michael Stone
On Fri, Jan 13, 2006 at 04:29:15PM -0500, Neil Conway wrote: There's really no additional operations required: INSERT INTO t2 VALUES (currval('t1_id_seq'), ...); You need a separate SELECT if you want to use the generated sequence value outside the database, That would, of course, be the goal.

Re: [PERFORM] insert without oids

2006-01-13 Thread Neil Conway
On Fri, 2006-01-13 at 15:10 -0500, Michael Stone wrote: > OIDs seem to be on their way out, and most of the time you can get a > more helpful result by using a serial primary key anyway, but I wonder > if there's any extension to INSERT to help identify what unique id a > newly-inserted key will ge

Re: [PERFORM] insert without oids

2006-01-13 Thread Michael Fuhr
On Fri, Jan 13, 2006 at 03:10:11PM -0500, Michael Stone wrote: > Are there plans on updating the insert API for the post-OID world? Are you looking for this TODO item? * Allow INSERT/UPDATE ... RETURNING new.col or old.col This is useful for returning the auto-generated key for an INSERT. On

[PERFORM] insert without oids

2006-01-13 Thread Michael Stone
OIDs seem to be on their way out, and most of the time you can get a more helpful result by using a serial primary key anyway, but I wonder if there's any extension to INSERT to help identify what unique id a newly-inserted key will get? Using OIDs the insert would return the OID of the inserted r

Re: [PERFORM] Please Help: PostgreSQL performance Optimization

2006-01-13 Thread Frank Wiles
On Thu, 12 Jan 2006 01:32:10 +0100 Jamal Ghaffour <[EMAIL PROTECTED]> wrote: > I'm using the default configuration file, and i m asking if i have to > change some paramters to have a good performance. In general the answer is yes. The default is a pretty good best guess at what sorts of valu

Re: [PERFORM] Please Help: PostgreSQL performance Optimization

2006-01-13 Thread Jamal Ghaffour
Andrew Lazarus a écrit : Jamal Ghaffour wrote: CREATE TABLE cookies ( domain varchar(50) NOT NULL, path varchar(50) NOT NULL, name varchar(50) NOT NULL, principalid varchar(50) NOT NULL, host text NOT NULL, value text NOT NULL, secure bool NOT NULL, timestamp timestamp