Re: [HACKERS] effective_cache_size vs units
TL == Tom Lane [EMAIL PROTECTED] writes: TL Personally I don't find the argument about someday we might want TL to support measurements in millibits to be convincing at all, and TL certainly it seems weaker than the argument that units should be TL case insensitive because everything else in this file is. The SQL TL spec has to be considered a more relevant controlling precedent TL for us than the SI units spec, and there are no case-sensitive TL keywords in SQL. Units simply are not case sensitive. They are just a more or less random collection of preexisting symbols, because that was easier than drawing up entirely new ones. Not all are English letters, for one µ is not. If you upper case a text with units in, the units do not change with the rest of the text. /Benny ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] effective_cache_size vs units
JCN == Jim C Nasby [EMAIL PROTECTED] writes: JCN Truth is, I bet many (if not most) DBAs barely know that case JCN matters in the units. Sounds like the school system needs fixing, then. /Benny ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] effective_cache_size vs units
TL == Tom Lane [EMAIL PROTECTED] writes: TL Anyone against making it case-insensitive, speak now or hold your TL peace. SI-units are inherently case-sensitive. The obvious example is that now you will allow people to specify an amount in millibytes, while interpreting it in megabytes. You are trying to interpret valid input as misspellings based on context, and then you silently guess at what the user really meant. That's MySQL behaviour! /Benny ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] New CRC algorithm: Slicing by 8
MK == Mark Kirkwood [EMAIL PROTECTED] writes: MK Here are the results after building gcc 4.1.2 (repeating results MK for gcc 3.4.6 for comparison). I suspect that performance is MK probably impacted because gcc 4.1.2 (and also the rest of the MK tool-chain) is built with gcc 3.4.6 - but it certainly suggests MK that the newer gcc versions don't like the slice-8 algorithm for MK some reason. They don't seem to like the old CRC algorithms either. It is quite strange, such dramatic performance regressions from 3.x to 4.x are rare. /Benny ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Upgrading a database dump/restore
TL == Tom Lane [EMAIL PROTECTED] writes: TL (I suppose it wouldn't work in Windows for lack of hard links, but TL anyone trying to run a terabyte database on Windows deserves to TL lose anyway.) Windows has hard links on NTFS, they are just rarely used. /Benny ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Query Failed, out of memory
MW == Mark Woodward [EMAIL PROTECTED] writes: MW Yea, I've been toying with the idea of that setting lately, I MW can't for the life of me understand why it isn't the default MW behavior. Lots of programs handle malloc() failures very badly. Including daemons. Often it's better in practice to just keep going a little longer and see if you can squeeze by -- and then perhaps kill the memory hog, rather than some daemon getting a NULL and crashing. /Benny ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Faster StrNCpy
ZA == Zeugswetter Andreas DCP SD [EMAIL PROTECTED] writes: ZA Yes, but it obviously does not in some ports, and that was the ZA main problem as I interpreted it. strncpy is part of POSIX; I highly doubt anyone gets it wrong. Getting sane semantics from it does require manually writing null to the last location in the buffer. If you need the null byte padding feature of strncpy, it seems a bit silly to replace it with strlcpy. Particularly if the only reason is performance. Down that road lies pglibc. /Benny ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] DROP FUNCTION IF EXISTS
CN == Csaba Nagy [EMAIL PROTECTED] writes: CN The full story is that I typed 'ü' (u-umlaut if it won't render CN correctly) and backspace before the '1'. I guess the backspace CN will delete byte-wise and will so fail to delete properly CN multi-byte characters. Backspace deletes character-wise, as long as you have LANG set correctly. Check LANG and the LC_* environment variables. /Benny ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] That EXPLAIN ANALYZE patch still needs work
MvO == Martijn van Oosterhout kleptog@svana.org writes: MvO What we want is just a monotonically increasing counter that can MvO be read quickly and consistantly, we're not majorly fussed if it MvO doesn't match real time. This puts us back to CPU cycle counters, MvO but they have drawbacks of their own. It is amazing how this discussion is mirroring discussions on the linux-kernel list. Applications have been using CPU cycle counters on Linux to avoid the gettimeofday() overhead. With reasonably recent kernels, the overhead is very low when the CPU cycle counters are usable, because gettimeofday() never actually enters kernel space. Unfortunately fewer and fewer systems seem to have usable cycle counters. As an example, dual core Athlon64/Opteron boots with the cycle counters unsynced. The kernel can compensate for that. However they also lose sync whenever clock frequency changes, and the kernel has a really hard time compensating for it. On such systems the kernel switches back to slower timers and gettimeofday() becomes a real system call. Applications should not try to use cycle counters directly on such systems. If the kernel developers manage a good workaround, gettimeofday() becomes fast again, but applications which use cycle counters most likely stay broken. Basically either gettimeofday() is fast, or the cycle counters are useless -- unless you really care about counting CPU cycles and not real time. Some CPUs like Transmetas actually get the counter thing right and count 2 every tick when running at half speed and so on. /Benny ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] GPUSort project
MvO == Martijn van Oosterhout kleptog@svana.org writes: MvO Is this of practical use for run-of-the-mill video cards? -- The article suggests that using the GPU is a win even on a $100 64MB card. The built-in card in most servers is probably not worth bothering with, but many servers offer PCI Express these days. /Benny ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
