Re: [HACKERS] A single escape required for log_filename
Robert Haas wrote: Joshua D. Drake j...@commandprompt.com writes: When I set it up, it automatically appended the time so I got: postgresql.log.1231878270 That seems a bit, well wrong. If I say I want postgresql.log I should get postgresql.log. You'd probably reconsider around the time the log file filled your disk. You really *don't* want a single fixed filename, you want some kind of rotation series. Clearly so, but it does seem a bit odd if there's really NO way to insist on a particular fixed filename. Indeed ... some of us have scripts that count on a given name. Fiddling them to look for the most recent seems like an unwarranted bit of busy work. Or am I missing something ? If I _want_ a foot-deringer, isn't that my business ? My $0.02 worth (less and less, every day) Greg Williamson Senior DBA DigitalGlobe Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and must be protected in accordance with those provisions. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. (My corporate masters made me say this.)
Re: [HACKERS] Keeping creation time of objects
Andrew Dunstan wrote: ... Can someone please give a good, concrete use case for this stuff? Might be nice to have doesn't cut it, I'm afraid. In particular, I'd like to know why logging statements won't do the trick here. Please pardon the kibbitzer intrusion ... Informix has this feature and I've often yearned for it in PostgreSQL (although it is low on my personal priorities). Typical use case I've run into is working on legacy databases where the original DBA is gone or senile (deprecating self-reference not to applied to any one on this list) and I need to make sense of a muddle of similarly named tables or functions with the same structure but different row counts or variant codings. The logs have long since been offlined to gosh knows where or lost -- we're talking 5 or more years of activity -- and even scripts may be suspect (the checked in script might refer to an original table but the DBA made on the fly changes) or some other DBA-like creature did things without proper procedures being followed. Having that date has been critical to resolving those issues of which table came in which order. It also gives a time window to use to go check old emails, archives, etc. for more information. Last update of data seems prohibitively expensive; if a user wants that a trigger and a 2nd table could well do that. Last DDL mod ... I could see the use but my old workhorse doesn't offer it so it never occurred to me to want it. Until know. '-) But this request is adding metadata, I agree. But with my vague understandings adding a date or time stamp for table creation wouldn't be a large bloat and if only required at creation seems low overhead. But maybe only bad DBAs need it. Or good DBAs who inherit systems from bad ones ? Sorry for the crufty posting -- my web client has recently deteriorated in terms of message formatting. Greg Williamson Senior DBA DigitalGlobe Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and must be protected in accordance with those provisions. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. (My corporate masters made me say this.)
Re: [HACKERS] Extending varlena
David Fetter wrote ... This'd greatly simplify the cleanup-dead-objects problem, and we could avoid addressing the permissions problem at all, since regular SQL permissions on the table would serve fine. But it's not clear what regular SQL fetch and update behaviors should be like for such a thing. (Fetching or storing the whole blob value is right out, IMHO.) ISTR hearing of concepts roughly like this in other DBs --- does it ring a bell for anyone? Informix has some pretty good blob-handling: http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.sqlr.doc/sqlrmst101.htm Agreed. I used Informix a few years back in a system that scanned both sides of multi-page financial documents; we stored them in Informix' blobs, which IIRC could be tuned to be given number of bytes. We found that 90% of our images fit in a given size and since Informix raw disk access let them move up the whole blob in a single pass, it was quite fast, and gave us all the warmth and fuzziness of ACID functionality. But we didn't fetch parts of the BLOB -- metadata lived in its own table. There is/was an Illustra/Informix blade which let you in theory do some processing of images (indexing) but that seems like a very specialized case. Greg Williamson Senior DBA DigitalGlobe Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and must be protected in accordance with those provisions. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. (My corporate masters made me say this.)
Re: [HACKERS] A new take on the foot-gun meme
In further OT Gregory Stark wrote: Shane Ambler [EMAIL PROTECTED] writes: Robert Treat wrote: So is that a golf club gun? Careful what you wish for http://www.totallyabsurd.com/12gaugegolfclub.htm I reckon they watched Caddyshack (I think that was the one) and thought they could get the patent before someone actually tried selling them. Surely a movie counts as published!? No the term is prior art leaving the lawyers to bill $400/hour while they argue over whether or not Caddyshack is art. Though the movie might have inspired this: http://www.rodenator.com/ http://video.google.com/videoplay?docid=2386436112453851581 http://www.youtube.com/watch?v=2umEFHeo6mw Looks fun as long as you don't do this: http://uk.reuters.com/article/oddlyEnoughNews/idUKN2432304520080326 In something of the same vein: http://news.bbc.co.uk/2/hi/americas/4593682.stm ... IMHO the pendejo got what was coming to him, though. Back to work, but I really appreciate some of the meanderings here. Greg Williamson Senior DBA DigitalGlobe Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and must be protected in accordance with those provisions. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. (My corporate masters made me say this.)
Re: [HACKERS] Creating a VIEW with a POINT column
Nick wrote: I have a VIEW that consists of two tables, of which contain a POINT column. When trying to select from the view I get an error... ERROR: could not identify an ordering operator for type point HINT: Use an explicit ordering operator or modify the query. Any suggestions??? -Nick I'm a lurker on this list (came for the 8.3 release, stayed for the delightful banter), but I have noticed that seems to be a real issue, at least for the moment. Not trying to be snotty, but perhaps using postGIS http://postgis.refractions.net/ would be a suitable alternate ? It does require admin rights to install but the point does have an equality op, GIST indexing and is reasonably light-weight in disk space. Ok, you probably already rejected this for good reason ... back to the real thread. Apologies for the signage below ... Greg Williamson Senior DBA DigitalGlobe Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and must be protected in accordance with those provisions. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. (My corporate masters made me say this.)
Re: [HACKERS] [GSoC08]some detail plan of improving hash index
Greg Smith wrote On Fri, 16 May 2008, Josh Berkus wrote: For a hard-core benchmark, I'd try EAStress (SpecJAppserver Lite) This reminds me...Jignesh had some interesting EAStress results at the East conference I was curious to try and replicate more publicly one day. Now that there are some initial benchmarking servers starting to become available, it strikes me that this would make a good test case to run on some of those periodically. I don't have a spare $2K for a commercial license right now, but there's a cheap ($250) non-profit license for EAStress around. That might be a useful purchase for one of the PG non-profits to make one day though. I (an individual, not me ex-cathedra) could pony up the geld for such a license if it is useful; let me know if so and where to do so. Greg Williamson Senior DBA DigitalGlobe Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and must be protected in accordance with those provisions. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. (My corporate masters made me say this.)
Re: [HACKERS] 8.3devel slower than 8.2 under read-only load
FWIW, Please do tests of at least 2 minutes duration. A 1.25 second test isn't enough. Please confirm you have VACUUM ANALYZED each db beforehand. Have you checked that the EXPLAIN ANALYZEs are essentially identical also? Is the data identical on both systems? I've been running some fairly heavy read-only tests (5 minutes duration) against 8.3beta2 and 8.2.5 and 8.1.10 and are getting slightly faster numbers for 8.2.5 over 8.1 and 8.3beta2 looks consistently faster by a few percent. This is heavily oriented to postGIS queries so your mileage may vary. But so far I haven't seen any red flags or show stoppers from my (limited) perspective. There are some changes to the config files but I don't have details at hand. Initial tests are always faster; we usually throw them out and run for real numbers starting with 3rd tests to make sure we don't jump at cache issues. For the most part we only care about performance with as much of the database in cache as we can so those initial tests aren;t of much use. (Sorry for the poor posting -- challenged mail client) HTH, Greg Williamson Senior DBA GlobeXplorer LLC, a DigitalGlobe company Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and must be protected in accordance with those provisions. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. (My corporate masters made me say this.)
Re: [HACKERS] psql show dbsize?
Sorry for top-posting -- challenged reader. Perhaps a future addition as \L ? This command doesn't seem to be used and could be documented as being subject to permissions and slower. I actually would find this useful, but there are other ways of getting it. But having the option would be nice sometimes IMHO. [I've been testing 8.3beta1 with no issues and have just installed the beta2 release, hence I've been lurking on this list. No errors other than self-inflicted ones.] Greg Williamson Senior DBA GlobeXplorer LLC, a DigitalGlobe company Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and must be protected in accordance with those provisions. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. (My corporate masters made me say this.) -Original Message- From: [EMAIL PROTECTED] on behalf of Tom Lane Sent: Wed 10/31/2007 5:44 PM To: Andrew Dunstan Cc: andy; PostgreSQL-development Subject: Re: [HACKERS] psql show dbsize? Andrew Dunstan [EMAIL PROTECTED] writes: Perhaps both these considerations dictate providing another command or a special flavor of \l instead of just modifying it? I've seen no argument made why \l should print this info at all. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
