[PERFORM] slow delete due to reference

) 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 rik...@ngs.hr 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

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

. 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] limit is sometimes not pushed in view with order

On Sat, 13 Apr 2013 11:21:19 -0400 Tom Lane t...@sss.pgh.pa.us 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

[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] self join revisited

Tom Lane wrote: Rikard Pavelic rikard.pave...@zg.htnet.hr 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 they do produce

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

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...

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

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

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