Re: PostgreSQL, MySQL, etc., was Re: PostgreSQL is much faster than MySQL, only when...
От | Randolf Richardson |
---|---|
Тема | Re: PostgreSQL, MySQL, etc., was Re: PostgreSQL is much faster than MySQL, only when... |
Дата | |
Msg-id | Xns9441AD1165AF0rr8xca@200.46.204.72 обсуждение исходный текст |
Ответ на | Re: PostgreSQL is much faster than MySQL, only when... (Marek Lewczuk <newsy@lewczuk.com>) |
Список | pgsql-general |
> Randolf Richardson Wrote: >> 2. Moving to table spaces (PostgreSQL version 8 maybe?) rather >> than just storing a whole bunch of files in a single directory. Oracle's >> implementation is nice because tables, indexes, etc., can span multiple >> table spaces, and there are great performance optimization and scalability >> advantages that otherwise just aren't possible without them. I read in >> another thread (approx. 2 months old) earlier this evening that some folks >> would like to see OIDs deprecated, and if this is the case then the sub- >> directories under "base/" will obviously need a different naming > mechanism, >> so instead of re-thinking this perhaps it would be a good opportunity for >> the PostgreSQL team to look at the possibility of implementing things >> within table spaces. > > I believe this is being worked on also. Yes!!!!!!! That's excellent! I look forward to helping with testing it on the NetWare port (and possibly FreeBSD if I ever get it running). [sNip] >> A very interesting idea, but my feeling is that pure PERL is best >> suited for dealing with flat text files. > > True,. and I use it for that (see my project at > http://sourceforge.net/projects/fwreport). However the ability to take a > similar parser and then use it to present the same information to a RDBMS > would then provide some additional flexibility, as you could use the RDBMS > for managing the query interface to the files. Not very useful if you only > want to see the same files the same way every time, but very useful if you > need to extract different information from them. [sNip] Obviously there's no disagreement here from anyone about the usefulness of this. I guess I should have clarified a bit more in my post because I'm concerned about PostgreSQL getting too fragmented from a project management perspective -- it's a database engine, with many different interfaces available, and to make it into a "Swiss Army Knife" (or a Chinese knock-off I saw once which had even more functionality) could result in possibly slower productivity in the long run (not to mention greater system resource requirements, &c). Albeit that's only a concern -- those developers who do all the hard work on PostgreSQL would obviously know best what the answer to this is. -- Randolf Richardson - rr@8x.ca Vancouver, British Columbia, Canada Please do not eMail me directly when responding to my postings in the newsgroups.
В списке pgsql-general по дате отправления: