Re: [HACKERS] ARC patent
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Simon Riggs wrote: > >>So, it also seems clear that 8.0.x should eventually have a straight >>upgrade path to a replacement, assuming the patent is granted. We >>should therefore plan to: 1. improve/replace ARC for 8.1 2. backport >>any replacement directly onto 8.0STABLE as soon as any patent is >>granted > > One of the reasons for Postgres' well deserved reputation for > stability and reliability is that stable branches are > ... stable. Backporting a large item like cache replacement mechanism > doesn't seem to fit that too well. I wouldn't want to do that except > as a complete last resort. Exactly, which is why it probably won't happen. Tom's got the right idea. Simply release 8.0, and then start planning for 8.1. If and when IBM gets this patent approved, and if and when IBM starts sending out letters then PostgreSQL will be prepared with non-infringing versions. The *real* moral of the story, however, is that it is not smart for developers to go poking through patent databases. The real problems with patents begin when the patent holder can prove that you *knew* about an *approved* patent and still released the software anyhow. So don't browse through the patent databases, and for heaven's sake, if you find a patent that PostgreSQL *might* be infringing whatever you do don't post about it on the PostgreSQL mailing lists. I am not a lawyer, but I think that the only sane thing to do is to follow the lead of the Linux kernel developers and stay away from any sort of patent research. You really don't want to know how many patents PostgreSQL is infringing, and you certainly don't want to talk about it on a public forum (or anywhere else). My guess is that IBM isn't likely to be interested in spending millions of dollars litigating agains the PostgreSQL project and various PostgreSQL end users. Suing customers (and potential customers) is always bad form, and chasing after a Free Software project is likely to be a PR disaster. However, even if IBM were interested in "cashing in" on this patent, they can't do that until the patent is actually granted. Jason ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Adding column comment to information_schema.columns
Andreas Pflug <[EMAIL PROTECTED]> writes: > Justin Clift wrote: > >> Tom Lane wrote: >> >>> >>> This question has been touched on before, but I guess it's time to >>> face it fair and square: is it reasonable for an SQL >>> implementation to add implementation-specific columns to an >>> information_schema view? One could certainly argue that the >>> entire point of information_schema is to be *standard*, not more, >>> not less. OTOH I do not know if adding an extra column is likely >>> to break anyone's application. Comments? >> >> >> Well, I suppose it reduces application portability if anyone starts >> relying on it. > > > We're advertising to do pure ANSI, so we'd mislead people if we > supplied non-standard columns. Yes, but if folks wanted to stick to the standard PostgreSQL would still work. The only difference is that people who aren't concerned about being more tied to PostgreSQL would get some extra features. There is a huge difference between adhering to a standard and limiting yourself to a standard. The real question is whether PostgreSQL's goal is to support SQL standards, or whether PostgreSQL's goal is to give PostgreSQL users a useful set of tools. Jason Earl ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Robert Treat <[EMAIL PROTECTED]> writes: > On Tuesday 27 April 2004 15:12, Alvaro Herrera wrote: >> You know, that's kind of the point of all things related to MySQL. >> "It's better than nothing." PostgreSQL doesn't do things because >> "it's better than nothing." (Same as how MySQL guesses the >> result of a modulo operation, and gets it wrong. They don't care >> and you can read that on the manual. In Postgres, this is a bug.) >> > > Hey Alvaro, are you familiar with "worse is better" philosphy in > software development and how that leads to adoption rates? It > basically states that simplicity is the ultimate design goal over > correctness, consitency, and completness. Because of this more > people are able to quickly adopt a technology, which allows the > incorrectness/inconsistency/incompletness to be address by new > comers and gradually bring the software up to higher standards. I > was reading some blogs the other day that applied this to PHP's > adoption rate over Java and .net, but your comment made me think > this really applies to my$ql and postgresql as well. check out > http://www.sitepoint.com/forums/showpost.php?p=1121502&postcount=2 > for a bit more. The problem with the "Worse is Better" philosophy is that it almost totally overlooks price, which is arguably the most important factor in deciding which technologies get adopted. The real trick is being "good enough" at the lowest price. When MySQL became the de-facto web database (back in the Postgres95 and Postgres 6.X days) PostgreSQL simply wasn't "good enough" for most sites. PostgreSQL, in those days, was slow, buggy, and decidedly non-standard (anyone else remember PostQUEL). On the plus side I personally don't think that Free Software databases have really hit their stride yet, and I believe that when they do PostgreSQL is going to be front and center. MySQL is a pretty handy datastore, but PostgreSQL is a far more useful tool for creating complex applications. Jason ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
Rod Taylor <[EMAIL PROTECTED]> writes: >> The difference is that a "better" admin tool is very subjective where as >> a buffer strategy is not... or maybe the difference is really that >> everyone thinks they are qualified to pick a "better" admin tool, but >> very few can really argue as to a better buffer strategy. While I think >> your criteria is pretty close to what I would use, I still couldn't pick >> which is the best between pgtcl/pgtclng/pgintcl or pypgsql/pygresql... >> and even I did I bet some people would have a problem with my choices. > > If you have a hard time picking between those projects, imagine the > difficulties someone who has never used PostgreSQL has just tracking > down the options available to them. Exactly. MySQL makes no bones about choosing "blessed" projects. I don't think that MySQL AB's MySQL Control Center is the best MySQL GUI, but it's better than the "default" PostgreSQL choice. MySQL shoves a workable solution under the end user's nose. PostgreSQL gives the potential user a wide array of choices, none of which are particularly easy to find. How many GUI tools are listed on GBorg? How many potential users even know to look at GBorg at all? One thing is certain most users aren't going to find psql (probably compiled without readline support) comparable with MySQL Control Center. Not to mention the fact that not having a set of "blessed" tools means that we end up with competing tools. PostgreSQL has several replication toolsets, piles of admin tools, and several competing language bindings for some of the most popular development languages. How many Python bindings does PostgreSQL need? PostgreSQL has some amazing supporting tools, but they are all hidden in an unlighted basement in a locked filing cabinet next to a sign that reads "Beware of the Leopard." > We would not be removing any choices for the user. We're simply > supplying a list of suggested tools that they may have interest in. Exactly. Yes, choosing tools requires some politics, and it will inevitably make some users and developers upset because their projects will get passed over for more popular ones. However, this will certainly help new users that are looking at PostgreSQL for the first time. They will be able to see, right off, what *sort* of tools are available for use with PostgreSQL. Later on as these people become part of the PostgreSQL community they might even find out about alternative tools that they like better. > Getting the user to download PostgreSQL and give it a shot without > becoming frustrated because the "basics" were not available (in an > obvious location) is the first step. PostgreSQL stacks up well as a database. In fact, it rocks. But comparing plain Jane PostgreSQL against other databases and their assorted suite of tools is not going to work in PostgreSQL's favor. Fortunately PostgreSQL has comparable supporting tools as well. Unfortunately no one knows about these tools except for those of us on the PostgreSQL lists. > Step 2 is to inform the user that there are more alternatives available. > I see pgFoundary doing a good job of #2 -- but it is not going to help > with #1 (too much choice is as bad as none at all to a beginner). Precisely. The trick is to promote PostgreSQL and a core set of tools. These tools don't have to be part of PostgreSQL's CVS (or even be available for download) from the postgresql.com site, but they should receive "top" billing. When the end user looks for a GUI, there should be a single solitary GUI that should be the "default" choice. When the end user asks about replication they should be guided to a single solution. In cases where it is difficult to decide what the default case might be--like in the case of replication where the tools you will want to use depends on what you are trying to accomplish--simply point users at the most common scenario and then document that they might need to use other tools to solve different problems. Jason ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-hackers-win32] [HACKERS] Tablespaces
"Thomas Swan" <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: [snip] > Apparently, I have failed tremendously in addressing a concern. The > question is does PostgreSQL need to rely on symlinks and will that > dependency introduce problems? > > There is an active win32 port underway (see this mailing list). > One proposal was to try to use an OS specific filesystem feature to > perform a symlink on NTFS. Can the special symlink that NTFS > allegedly supports be archived the same way symlinks are archived on > Unix? If so, is there a utility that can do this (zip, tar, etc). > The backup operator would still need to know what directories needed > to be archived in addtion to the pgdata directory. Is this > symlink structure a normal/special file that can be archived by > normal means (tar,zip, etc)? > > Example: > > PGDATA is C:\pgdata > I have a tablespace in Z:\1\ and Z:\2\ > There exists an alleged symlink in > C:\pgdata\data\base\tablespaces\schmoo -> Z:\1 > > Can I archive [ C:\pgdata, Z:\1, Z:\2 ], restore them, and have > postgresql working just as before? My point is that if you are using some sort of sytem table, catalog file, or whatever else (besides symlinks), you are still going to have to backup up c:\pgdata z:\1 and z:\2 manually anyhow. Unless, of course, you have some magical version of tar or zip that reads the PostgreSQL specific configuration file and somehow "does the right thing." At least with symlinks you have a fighting chance on some platforms of being able to do: tar zcvf /tmp/backup.tgz /usr/local/postgres/pgdata/ and have it do the right thing. Using PostgreSQL specific catalogs you would force UNIX users (the majority of PostgreSQL users right now) to back up their tablespaces manually. Forcing platforms with symlinks to use your wacky symlink replacement just guarantees that all platforms work equally poorly. It doesn't make the Win32 port any better. You would still have to backup c:\pgdata z:\1\ and z:\2\ separately on Win32. The only difference is that now your misery would have the company of all of the rest of us. >>>It seems a little insane to introduce an OS/filesystem dependency >>>at the onset of a porting effort especially if you hope to be OS >>>agnostic for feature sets. I think someone would be crying foul if >>>a new feature only worked on Linux and not on FreeBSD. >>> >> >>First of all, symlinks are a pretty popular "feature." Even Windows >>supports what would be needed. Second of all, PostgreSQL will still >>run on OSes without symlinks, tablespaces won't be available, but >>PostgreSQL will still run. Since we are all using PostgreSQL >>without tablespaces now, it can hardly be argued that tablespaces >>are a critical feature. >> >>We aren't talking about a "feature that work[s] on Linux on not on >>FreeBSD." We are talking about a feature that works on every OS >>that suports symlinks (which includes even operating systems like >>Windows that PostgreSQL doesn't currently support). > > Hello? What was this response from Tom Lane? "My feeling is that we > need not support tablespaces on OS's without symlinks." That seems to > be indicative of a feature set restriction base on platform. Tom Lane works for Red Hat. You can't hardly expect him to spend all of his time working around the limitations of the competition's operating system. >>>Additionally, another developer noted the advantage of a text file >>>is that it would be easy for someone to develop tools to help if it >>>became difficult to edit or parse. Additionally, there could be a >>>change away from a flat file format to an XML format to configure >>>the tablespace area. >> >>The advantage of symlinks is that no tools would have to be written >>and 'ls -l' would show everything you would need to know about where >>your tablespaces actually were. > > Where is 'ls -l' on a win32 box? If you will follow the discussion > of symlinks under MinGW you will see that they don't work as > commanded. And, postgresql is supposed to be compiled under MinGW, > but not require it to run. > > From Windows 2000, 'ls' is not recognized as an internal or external > command, operable program or batch file. Yes, Windows lacks 'ls', but it has similar tools. >>XML files are relatively easy to parse, but they certainly aren't as >>easy as simply letting PostgreSQL follow a symlink. Why reinvent the >>wheel with what would essentially be PostgreSQL's own implementation >>of a symlink? >> >> > > Is opening a file recreating a symlink? If you are opening file > descriptors why rely on symlinks. If you know the location either > from the system catalog, a or configuration file, is it any terribly > more complicated? Basically, if a tablespace needed to be renamed, > or moved, or changed, your going to have to do file management > anyway. The symlink saves you just a lookup as to what files go > where? If you kept this small hash in memory, it's not a continuous > lookup
Re: [pgsql-hackers-win32] [HACKERS] Tablespaces
<[EMAIL PROTECTED]> writes: >> [EMAIL PROTECTED] wrote: >>> > "Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes: >>> My feeling is that we need not support tablespaces on OS's without >>> symlinks. >>> > >>> >> To create symlinked directories on Win2k NTFS see: >>> >> http://www.sysinternals.com/ntw2k/source/misc.shtml#junction >>> >> I think Win2000 or XP would be a reasonable restriction for Win32 PG >>> >> installations that want tablespaces. >>> > >>> > Oh, good --- symlinks for directories are all that we need for this >>> > design. I think that settles it then. >>> > >>> >>> What archival tools are there that would restore this to this back to >>> the >>> filesystem: tar? zip? What would happen if a symlink were removed or >>> pointed to an invalid location while the postmaste was running? >> >> Well, for backup, just run tar or find on /data with a flag to >> follow symlinks, and you are done. Can't get much easier than >> that. > > I'm ruferring to NTFS and the win32 platforms. How does tar handle > these symlinks on the NTFS filesystem? What about if someone finds > that FAT32 is significantly better for the database? tar doesn't know anything about PostgreSQL system catalogs. If we use symlinks for tablespaces then it would be possible to backup downed databases with a simple tar command on every platform *I* care about (and probably Windows too). Using system catalogs for this stuff would simply guarantee that I would have to read the system catalogs and then back up each tablespace manually. In short, your idea would trade off (maybe) having to backup tablespaces manually on a few platforms for the certainty of having to backup tablespaces manually on all platforms. How is that a win? > It seems a little insane to introduce an OS/filesystem dependency at > the onset of a porting effort especially if you hope to be OS > agnostic for feature sets. I think someone would be crying foul if > a new feature only worked on Linux and not on FreeBSD. First of all, symlinks are a pretty popular "feature." Even Windows supports what would be needed. Second of all, PostgreSQL will still run on OSes without symlinks, tablespaces won't be available, but PostgreSQL will still run. Since we are all using PostgreSQL without tablespaces now, it can hardly be argued that tablespaces are a critical feature. We aren't talking about a "feature that work[s] on Linux on not on FreeBSD." We are talking about a feature that works on every OS that suports symlinks (which includes even operating systems like Windows that PostgreSQL doesn't currently support). > Additionally, another developer noted the advantage of a text file > is that it would be easy for someone to develop tools to help if it > became difficult to edit or parse. Additionally, there could be a > change away from a flat file format to an XML format to configure > the tablespace area. The advantage of symlinks is that no tools would have to be written and 'ls -l' would show everything you would need to know about where your tablespaces actually were. XML files are relatively easy to parse, but they certainly aren't as easy as simply letting PostgreSQL follow a symlink. Why reinvent the wheel with what would essentially be PostgreSQL's own implementation of a symlink? To go back to your *tar* example, are we going to rewrite tar so that it reads PostgreSQL's XML file and *does the right thing*? > Another argument against the symlink approach is how they may change > in the future. A file location is universal, symlink behavoir may > not be. The symlink behavior on different ports may change. To > rely on symlinks introduces an unnecessary OS dependency. All that > is needed is the file location. This can be derived from a flat > file, an XML file, a sysetm catalog. Yes, and someone can whip out vi and edit a file or fire up psql and change the system catalog. Heck, someone could issue a 'mv' or 'rm' command on the actual files, for that matter. PostgreSQL can't protect itself from careless sysadmins, and symlinks are no more inherently dangerous than normal files. They don't just *disappear*. > Also, to support some features on some platforms is a real poor > prospect. ( This application requires the Linux port of PostgreSQL > 7.5.1 ) seems like a poor choice for advocating PostgreSQL. The > extra effort insures that all ports, current and future, can get the > same set of features and nhancements. I like Unix and Linux as > much as the next guy, but I have to be real and make the presumption > that there are and will be other operating systems and it would be > wise to plan a little for that. The fact of the matter is that PostgreSQL runs better on some platforms than others, and it probably always will. Heck, as of today, PostgreSQL is officially supported on the Gamecube. Does that mean that the PostgreSQL developers should limit themselves to the features offered by the Gamecube? What, prec
Re: [HACKERS] Planning to force reindex of hash indexes
Tom Lane <[EMAIL PROTECTED]> writes: > "Mendola Gaetano" <[EMAIL PROTECTED]> writes: >> "Tom Lane" <[EMAIL PROTECTED]> wrote: >>> I've found a number of infelicities in the hash index code that >>> can't be fixed without an on-disk format change. > >> How can we avoid this kind of mess for the future ? > > Build a time machine, go back fifteen years, wave a magic wand to > increase the IQ levels of the Berkeley grad students? Sometimes we > just have to change bad decisions, that's all. > > regards, tom lane Actually, I think that your time would be better spent on the time machine. After all, with working time travel you wouldn't have to worry about optimizing PostgreSQL. Queries could take as long as they needed to take and then you could send the response back in time to right before the query was issued. It's too bad you don't have the time machine finished already. You could use the time machine to go back in time and work on the time machine :). You'd be finished in no time. Jason ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
