Comments for pko.ch

Comment on Taming git by pkoch

pkoch — Sun, 29 Jan 2012 23:25:17 +0000

@Rendeiro: None at all. It is, indeed, quite a different storage philosophy. I don’t know much about Mercurial’s storage internals (I think it’s purely diff based). However, Mercurial’s API is quite sane. When I needed some hardcore node action, I just whipped out python and import mercurial.

Comment on Taming git by Joaquim Rendeiro

Joaquim Rendeiro — Sun, 29 Jan 2012 09:49:04 +0000

I recently read something about one of the main differences between Mercurial and Git: the commit graph is not a blob, but something more transparent (and I guess more “unix-y”)… Did that make any difference in your switch from HG to Git?

Comment on Restored access to mail.google.com by Susanne @ Linksys Factory

Susanne @ Linksys Factory — Wed, 03 Nov 2010 02:06:08 +0000

Hello there, just wandered by. I have a Linksys site. Lots of information out there. Not quite what I was looking for, but nice site. Have a good day.

Comment on Selective access to mail.google.com by pkoch

pkoch — Tue, 01 Sep 2009 23:39:20 +0000

This was long ago. The current crash has nothing to do with my problems.

Comment on Selective access to mail.google.com by Ian Samson

Ian Samson — Tue, 01 Sep 2009 20:17:24 +0000

It appears Google’s GMail server has crashed. While I can traceroute and ping, any browser access to mail.google.com has vanished. This is utterly ridiculous! What happend??

Comment on For those who don’t use SQL too much, just like me. by pkoch

pkoch — Thu, 19 Feb 2009 00:07:23 +0000

Hmm. I’ll run some benchmarks and post them.

About the style, it varies. NOT IN is sometimes more legible, sometimes it’s NOT EXISTS.

Comment on For those who don’t use SQL too much, just like me. by André Restivo

André Restivo — Wed, 18 Feb 2009 00:56:12 +0000

Imagine this query from the link you gave above:

SELECT DISTINCT store_type FROM stores
WHERE NOT EXISTS (SELECT * FROM cities_stores
WHERE cities_stores.store_type = stores.store_type);

For each line of the outer query the inner query has to be computed again because stores.store_type changes. Of course MySQL can have an intelligent caching mechanism, but if the number of stores is very big it won’t be enough. If MySQL is really intelligent it will transform the query into something similar to what I proposed. I know for a fact that PostgreSQL doesn’t like this type of queries very much.

In the example I wrote before. The inner query has to be performed only once and then it’s just a matter of using the index wisely.

Have you tried both approaches with some big chunks of data? You won’t notice the difference with small tables.

IMHO I think that the NOT IN clause is easier to understand than the NOT EXISTS clause and also more elegant. But it’s a matter of taste really …

Comment on For those who don’t use SQL too much, just like me. by pkoch

pkoch — Wed, 18 Feb 2009 00:24:33 +0000

Hmm, that’s contradictory to my MySQL experience. How/where did you observe that behaviour?

Comment on For those who don’t use SQL too much, just like me. by André Restivo

André Restivo — Tue, 17 Feb 2009 23:24:10 +0000

select * from category
where category.id not in (select cat_id from cat_post where post_id = $the_post_id)

This way seems easier and it’s probably faster as DB usually don’t cope well with ‘exists’ clauses.

Comment on 02:30:00|pkoch@Kochs-PowerBook:~$ history | awk ‘{print $2}’ | sort | uniq -c | sort -rn | head by Manuel Parente

Manuel Parente — Wed, 29 Oct 2008 18:26:33 +0000

Hello,

157 say
90 cd
76 ls
32 chmod
9 sudo
9 rm
9 ping
9 man
8 ipconfig
7 php

That’s what i use Terminal for….