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

2015-10-08 Thread Laurent Martelli
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 tried

Re: [PERFORM] IS NOT NULL and LEFT JOIN

2014-10-21 Thread Laurent Martelli
Le Mardi 21 Octobre 2014 10:44 CEST, David Rowley 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 updated the > user_inf

Re: [PERFORM] IS NOT NULL and LEFT JOIN

2014-10-20 Thread Laurent Martelli
Le 20/10/2014 15:58, Tom Lane a écrit : Laurent Martelli 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 column might be nu

Re: [PERFORM] IS NOT NULL and LEFT JOIN

2014-10-20 Thread Laurent Martelli
d is not null does not use 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 mailto:laurent.marte...@enercoop.org>> wrote: Hello there, I have a strange query plan involv

[PERFORM] IS NOT NULL and LEFT JOIN

2014-10-18 Thread Laurent Martelli
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 di

Re: [PERFORM] Speeding up select distinct

2005-03-16 Thread Laurent Martelli
ures. I just wished there was a means to fully automate all this and render it transparent to the user, just like an index. Merlin> Voila! Merlin p.s. normalize your data always! I have this: pictures( PictureID serial PRIMARY KEY, Owner integer NOT NULL REFERENCES users, [...]); CREATE

Re: [PERFORM] Speeding up select distinct

2005-03-16 Thread Laurent Martelli
4.38 rows=21 width=4) (actual time=7.585..7.605 rows=21 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]

Re: [PERFORM] Speeding up select distinct

2005-03-16 Thread Laurent Martelli
>>>>> "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

[PERFORM] Speeding up select distinct

2005-03-16 Thread Laurent Martelli
for 20 rows. I looked at other 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]Jav

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

2004-07-12 Thread Laurent Martelli
tient. alix> Pour moi la même chose que l'année dernière : on y va. Idem pour moi. -- Laurent Martellivice-président de Parinux http://www.bearteam.org/~laurent/ http://www.parinux.org/ [EMAIL PROTECTED] ---

Re: [PERFORM] achat borne wifi

2004-07-10 Thread Laurent Martelli
avoir qq infos et des prix. Je pense que c'est un bon investissement. +1 donc -- Laurent Martellivice-président de Parinux http://www.bearteam.org/~laurent/ http://www.parinux.org/ [EMAIL PROTECTED] ---(en

Re: [PERFORM] VidéoProj -> RMLL

2004-06-29 Thread Laurent Martelli
é d'occasion sans facture et je Laurent> vois mal une assurance accepter de rembourser un appareil Laurent> sans cet élément. De mémoire, le gars nous avait filé la facture lorsqu'il nous l'a vendu. -- Laurent Martellivice

Re: [PERFORM] Pas la samedi

2004-06-24 Thread Laurent Martelli
odules) Laurent> Et subversion ? Puisqu'on a pas d'existant sous CVS à migrer, je suis aussi plutôt commencer directement avec subversion, qui est un CVS en mieux. -- Laurent Martellivice-président de Parinux http://www.bearteam.org/~laurent

Re: [PERFORM] Traduc Party

2004-06-23 Thread Laurent Martelli
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] Traduc Party

2004-06-23 Thread Laurent Martelli
anifestation maitenant et tu peux pas dire non ;) Ouf! Je suis soulagé de la tournure que ça prends. -- Laurent Martellivice-président de Parinux http://www.bearteam.org/~laurent/ http://www.parinux.org/ [EMAIL PROTECTED]

Re: [PERFORM] Query involving views

2004-06-06 Thread Laurent Martelli
>>>>> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes: Tom> Laurent Martelli <[EMAIL PROTECTED]> writes: >> Now, if I use the following view to abstract access rights: >> CREATE VIEW userpictures ( >> PictureID,RollID,FrameID,Des

[PERFORM] Query involving views

2004-06-06 Thread Laurent Martelli
Filter: ((value)::text = 'laurent'::text) -> Hash (cost=5.19..5.19 rows=12 width=8) (actual time=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]Java Aspect Components http://www.aopsys.com/ http://jac.objectweb.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] Unused table of view

2004-06-05 Thread Laurent Martelli
>>>>> "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> yiel

[PERFORM] Unused table of view

2004-06-05 Thread Laurent Martelli
(cost=100.28..100.37 rows=38 width=4) (actual time=0.091..0.094 rows=8 loops=1) Sort Key: topicscontent.pictureid -> Index Scan using topicscontent_topicid on topicscontent (cost=0.00..99.28 rows=38 width=4) (actual time=0.039..0.057 rows=8 loops

Re: [PERFORM] Join on incompatible types

2003-11-19 Thread Laurent Martelli
Shridhar> classes.id=lists.value::integer. With classes.id of type integer and lists.value of type varchar, I get "ERROR: Cannot cast type character varying to integer", which is not such a surprise. Thanks for your help anyway. -- Laurent Martelli [EMAIL PROTECTED]

Re: [PERFORM] Join on incompatible types

2003-11-19 Thread Laurent Martelli
>>>>> "Shridhar" == Shridhar Daithankar <[EMAIL PROTECTED]> writes: Shridhar> Laurent Martelli wrote: >>>>>>> "Shridhar" == Shridhar Daithankar >>>>>>> <[EMAIL PROTECTED]> writes: Shridhar&g

Re: [PERFORM] Join on incompatible types

2003-11-18 Thread Laurent Martelli
>>>>> "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 ? Shridh

[PERFORM] Join on incompatible types

2003-11-18 Thread Laurent Martelli
"inner".id) scott> This estimate is WAY off. Are both of those fields indexed scott> and analyzed? Have you tried upping the statistics target on scott> those two fields? I assume they are compatible types. Should I understand that a join on incompatible types (such as i