Slow query on object_pk
alexandredufour opened this issue · 3 comments
In class BaseCommentAbstractModel, is there a reason why you're using a TextField for "object_pk".
At first glance, I would recommend using a ForeignKey / IntegerField or at the very least a CharField.
Using TextField is really slow, especially in Postgres, compared to other types ( Integer / CharField )
Using TextField is really slow, especially in Postgres, compared to other types ( Integer / CharField )
Is this a theorical or an experienced slowdown?
TextField and CharField which map text and varchar SQL datatypes are both implemented using the same varlena data structure on PostgreSQL so I'd be surprised if the former performed worse than the latter.
Long story short, I've been to a conference given by Magnus Hagander ( He's one of Postgresql Core Team contributor ) about Postres Gotchas for developers.
At some points, he spoke about "TOAST" and how we should avoid TextField if not necessary.
I've tried to find more info on this (event did some benchmark), but I must say, at first glance, it seems there's no real performance gain between Text and varchar.
More to the point, is there a reason why object_pk shouldn't be an Integer?
More to the point, is there a reason why object_pk shouldn't be an Integer?
Simply because some PKs are not integer (think about uuids).