[PERFORM] slow delete due to reference

it didn't) Regards, Rikard -- Rikard Pavelic https://dsl-platform.com/ http://templater.info/ signature.asc Description: OpenPGP digital signature

Re: [PERFORM] limit is sometimes not pushed in view with order

On Sat, 13 Apr 2013 20:08:16 +0200 Rikard Pavelic wrote: > While one could argue that optimizer doesn't know to optimize left > join with group by its primary key, you can replace that join with > some other joins (ie left join to another table pk) and the same > behavior

Re: [PERFORM] limit is sometimes not pushed in view with order

On Sat, 13 Apr 2013 11:21:19 -0400 Tom Lane wrote: > The planner realizes that about 1/200th of the table satisfies the > "ord" condition, so it estimates that the first plan will require > scanning about 2000 entries in the pkey index to get 10 results. So > that looks significantly cheaper tha

[PERFORM] limit is sometimes not pushed in view with order

is a known behavior. Regards, Rikard -- Rikard Pavelic http://www.ngs.hr/ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] self join revisited

Tom Lane wrote: > Rikard Pavelic writes: > >> It would be great if Postgres could rewrite this query >> > > AFAICS those queries are not going to produce the same results, > so Postgres would be 100% incorrect to rewrite it like that for you. > > (If the

[PERFORM] self join revisited

How hard would it be to teach planer to optimize self join? While this query which demonstrates it is not that common SELECT count(*) FROM big_table a INNER JOIN big_table b ON a.id = b.id; This type of query (self joining large table) is very common (at least in our environment

Re: [PERFORM] [PERFORMANCE] Stored Procedures

Jim C. Nasby wrote: If you're dealing with something that's performance critical you're not going to be constantly re-connecting anyway, so I don't see what the issue is. I didn't include mailing list in my second reply :( so here it is again. Someone may find this interesting... http://arc

Re: [PERFORM] [PERFORMANCE] Stored Procedures

Jim C. Nasby wrote: If you're dealing with something that's performance critical you're not going to be constantly re-connecting anyway, so I don't see what the issue is. I really missed your point. In multi user environment where each user uses it's connection for identification purposes,

Re: [PERFORM] [PERFORMANCE] Stored Procedures

Jim C. Nasby wrote: My college professor said it, it must be true! ;P The famous joke ;) My understanding is that in plpgsql, 'bare' queries get prepared and act like prepared statements. IE: SELECT INTO variable field FROM table WHERE condition = true ; Unfortunately I don

Re: [PERFORM] Stored procedures

Hi, Will simple queries such as "SELECT * FROM blah_table WHERE tag='x'; work any faster by putting them into a stored procedure? IMHO no, why do you think so? You can use PREPARE instead, if you have many selects like this. I tought that creating stored procedures in database means

Re: [PERFORM] [PERFORMANCE] Stored Procedures

Hi, Will simple queries such as "SELECT * FROM blah_table WHERE tag='x'; work any faster by putting them into a stored procedure? IMHO no, why do you think so? You can use PREPARE instead, if you have many selects like this. I tought that creating stored procedures in database means stor