Re: [PERFORM] Join on incompatible types

Shridhar == Shridhar Daithankar [EMAIL PROTECTED] writes: Shridhar Laurent Martelli wrote: [...] Should I understand that a join on incompatible types (such as integer and varchar) may lead to bad performances ? Shridhar Conversely, you should enforce strict type compatibility

[PERFORM] Unused table of view

) (actual time=0.039..0.057 rows=8 loops=1) Index Cond: (topicid = 137) Total runtime: 31.376 ms -- Laurent Martelli [EMAIL PROTECTED]Java Aspect Components http://www.aopsys.com/ http://jac.objectweb.org

Re: [PERFORM] Unused table of view

Tom == Tom Lane [EMAIL PROTECTED] writes: Tom Laurent Martelli [EMAIL PROTECTED] writes: The pictures table is scanned, but it's not needed. Tom Yes it is. For example, if pictures is empty then the view Tom yields zero rows. Omitting the join to pictures could give a Tom different

[PERFORM] Query involving views

=0.198..0.198 rows=0 loops=1) - Seq Scan on groupsdef (cost=0.00..5.19 rows=12 width=8) (actual time=0.031..0.178 rows=11 loops=1) Filter: (userid = 2) Total runtime: 35.657 ms -- Laurent Martelli [EMAIL PROTECTED

Re: [PERFORM] Traduc Party

prends. -- Laurent Martellivice-président de Parinux http://www.bearteam.org/~laurent/ http://www.parinux.org/ [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe

Re: [PERFORM] Traduc Party

How in hell did could this mail be sent to pgsql-performance ??? I must have inadvertently hit a fatal and obscure keystroke in Emacs/Gnus. Sorry for the noise. -- Laurent Martelli [EMAIL PROTECTED]Java Aspect Components http://www.aopsys.com

Re: [PERFORM] Pas la samedi

est un CVS en mieux. -- Laurent Martellivice-président de Parinux http://www.bearteam.org/~laurent/ http://www.parinux.org/ [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have

Re: [PERFORM] VidéoProj - RMLL

élément. De mémoire, le gars nous avait filé la facture lorsqu'il nous l'a vendu. -- Laurent Martellivice-président de Parinux http://www.bearteam.org/~laurent/ http://www.parinux.org/ [EMAIL PROTECTED

Re: [PERFORM] achat borne wifi

donc -- Laurent Martellivice-président de Parinux http://www.bearteam.org/~laurent/ http://www.parinux.org/ [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading

Re: [PERFORM] Fw: invitation au Village du Logiciel Libre de la

. -- Laurent Martellivice-président de Parinux http://www.bearteam.org/~laurent/ http://www.parinux.org/ [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive

[PERFORM] Speeding up select distinct

type of indexes, but they seem to either not give beter perfs or be irrelevant. Any ideas, apart from more or less manually maintaining a list of distinct owners in another table ? -- Laurent Martelli [EMAIL PROTECTED]Java Aspect Components http://www.aopsys.com

Re: [PERFORM] Speeding up select distinct

Rod == Rod Taylor [EMAIL PROTECTED] writes: Rod On Wed, 2005-03-16 at 18:58 +0100, Laurent Martelli wrote: Consider this query: SELECT distinct owner from pictures; Rod The performance has nothing to do with the number of rows Rod returned, but rather the complexity

Re: [PERFORM] Speeding up select distinct

loops=1) - Seq Scan on pictures (cost=0.00..103.70 rows=4270 width=4) (actual time=0.015..3.272 rows=4270 loops=1) Total runtime: 7.719 ms -- Laurent Martelli [EMAIL PROTECTED]Java Aspect Components http://www.aopsys.com/ http

[PERFORM] IS NOT NULL and LEFT JOIN

Hello there, I have a strange query plan involving an IS NOT NULL and a LEFT JOIN. I grant you that the query can be written without the JOIN on user_user_info, but it is generated like this by hibernate. Just changing the IS NOT NULL condition to the other side of useless JOIN makes a big

Re: [PERFORM] IS NOT NULL and LEFT JOIN

any *new* information from user_user_info. Regards, Laurent Le 19/10/2014 10:41, David Rowley a écrit : On Sun, Oct 19, 2014 at 5:10 PM, Laurent Martelli laurent.marte...@enercoop.org mailto:laurent.marte...@enercoop.org wrote: Hello there, I have a strange query plan involving

Re: [PERFORM] IS NOT NULL and LEFT JOIN

Le 20/10/2014 15:58, Tom Lane a écrit : Laurent Martelli laurent.marte...@enercoop.org writes: Do we agree that both queries are identical ? No, they *aren't* identical. Go consult any SQL reference. Left join conditions don't work the way you seem to be thinking: after the join, the RHS

Re: [PERFORM] IS NOT NULL and LEFT JOIN

Le Mardi 21 Octobre 2014 10:44 CEST, David Rowley dgrowle...@gmail.com a écrit: For what it's worth I'd say they are identical, at least, if you discount deferring foreign key constraints or also executing the query from within a volatile function which was called by a query which just

Re: [PERFORM] One long transaction or multiple short transactions?

Le 08/10/2015 01:40, Carlo a écrit : >> How many cores do you have on that machine? Test if limiting number of simultaneous feeds, like bringing their number down to half of your normal connections has the same positive effect. << I am told 32 cores on a LINUX VM. The operators have