Comments for pko.ch

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

Comment on Memoization in Python: easier than what it should be by pkoch

pkoch — Mon, 25 Aug 2008 01:16:50 +0000

Illustrative example:

@memoize
def prt(*args,**kwargs):
    print "Calculated!"
    return (args,kwargs)

a = [1,2,3]
print prt(a,one=10, c='cee', d2='two')

a.append(1)
print prt(a, one=10, c='cee', d2='two')
print prt(a, one=10, d2='two', c='cee')

a.pop()
print prt(a, c='cee',one=10, d2='two')

Comment on Memoization in Python: easier than what it should be by pkoch

pkoch — Mon, 25 Aug 2008 00:05:31 +0000

I’ve updated my post to reflect many of the improvements presented on reddit comments.

Thank you, all! =)

Comment on There’s no silver bullet, but there’s a silver DSCM. And it’s quick. by pkoch

pkoch — Sun, 24 Aug 2008 23:56:38 +0000

Jakub Narębski:

Maybe the video I referred has some mention to it, can’t really recall where i stumbled into that. I remember that someone said Mercurial started as a conceptual branch from Git exactly on that point. But that’s just what I remember. Your right, I should have backed up my claims.

Mercurial has just the amount of complexity I’ve ever wanted. I’ve bettered my understanding of Git since I first wrote that post, and didn’t find any of its added functionality over Mercurial to ease my life. The less complexity I have to deal with, the better. Mercurial is more than enough for me.