#2324: Increase length of Permission.permission_name
------------------------+---------------------------------------------------
Reporter: pitrou | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: TurboGears | Version: 2.0b7
Severity: trivial | Resolution:
Keywords: |
------------------------+---------------------------------------------------
Comment (by Gustavo):
Replying to [comment:4 pitrou]:
> I question both the meaning and relevance you give to these documents:
> - The Oracle example is for a table of 8,388,608 rows (!)
Well, benchmarks always use big values to make differences notable.
> - The MySQL doc says "When MySQL will need to do the sort it will use
corresponding fixed length field format, which will lead to larger
temporary file and so slower sorting.". Sure, but you don't sort
permissions by permission_name. Actually, you don't sort permissions at
all.
Good point, it was a bad reference in this context.
> - As for the MS SQL docs, they don't explicitly state that VARCHAR with
a large size are a bad thing. They seem to talk about size of fixed-length
columns.
"'''The narrower the column''', the less amount of data SQL Server has to
store, and the faster SQL Server is able to read and write data"... That
doesn't refer to fixed-length columns.
> In any case, the fact that a typical application will only have 5 to 10
different permissions, and the richest applications perhaps 50 to 100 of
them, seems to make the whole objection gratuitous. Querying such a data
set will be blazingly fast, whatever the exact column types, on any decent
DBMS.
The column size does affect performance, at least a little bit. So, I
think it's good to have a narrow column by default... After all,
developers will always be able to change that.
I'm not strongly opposed to increasing it, though. If more people think it
should be increased, it'd be fine by me.
> Ironically, the fact that no Index is defined in model/auth.py is
probably much more detrimental to performance (for non-trivial datasets)
than the size of the various columns.
> (PostgreSQL doesn't automatically create an index for each foreign key ;
you have to manually create indexes yourself if you want to speed up joins
along those foreign keys. "EXPLAIN SELECT" tells me that currently,
PostgreSQL will do a sequential scan when joining between the various auth
tables)
That's indeed a good point, could you please open another ticket for that,
so we won't forget? I could do it, but I'm a rush now
--
Ticket URL: <http://trac.turbogears.org/ticket/2324#comment:5>
TurboGears <http://www.turbogears.org/>
TurboGears front-to-back web development
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "TurboGears Tickets" group.
This group is read-only. No posting by normal members allowed.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/turbogears-tickets?hl=en?hl=en
-~----------~----~----~----~------~----~------~--~---
