Slashdot Mirror

Meanwhile, MySQL is now doing transactions, and VIEWs are on their way in 5.1.

Is it going to have a data type for IP addresses in the next release, too?

It really, truly astounds me that MySQL has caught on as a DBMS for Internet-facing applications -- including logging, network management, and so forth -- when (at least as of the versions I've seen) it doesn't have data types or operations for IP addresses or CIDR blocks. My partner is in the middle of a CMU NetReg deployment. CMU NetReg is a MySQL-backed Perl application for allowing authenticated users to register their computers into a DHCP network. It has to store all IP addresses as integers, and do binary math in Perl, because the DBMS is too stupid to tell whether 10.128.128.52 is in 10.128.128.0/24.

(Note, I'm not talking about the internal representation of IP addresses. Obviously IP addresses are 32-bit integers. I'm talking about what you see when you do SELECT ip_addr FROM hosts and get 167870644 instead of an IP address. I'm talking about whether the database can compare IP addresses, SELECT those addresses in a netblock, and so forth. Or, as with most things MySQL, you have to implement basic data manipulation in your application because the DBMS can't be arsed.)

Meanwhile, PostgreSQL has IPv4, IPv6, netblock, and MAC address data types and built-in functions to process them. Those make it a darn sight easier to write network management programs, or any other program that needs to reason about IP addresses.

never actually had to think about that question before, however a quick look at their faq seemed to indicate it's in progress.

How about ANSI '92 compliance for MySQL... that would be a good start!

Meanwhile, MySQL

Meanwhile, PostgreSQL is more free (as in the BSD license so you can actually use it without danger of being sued or having your license revoked by anybody). And PgSQL has more features and is reported to handle greater loads than MySQL (where MySQL would simply fail or crash).

Most of the trolls are lying about mysql, I am a database administrator and I can tell you that Postgresql already is a lot better than sql server. If you disaggree, you are not using the latest version.

OpenSource is already ahead, so stop trolling!

i think you'll find PostgreSQL is also pretty good value for money!

Postgresql is underdocumented, the MySQL online documentation simply excels.

Complete and utter bullshit. How is this for documentation? There are also excellent books about it.

There is no readily available workforce that has actual Postgresql knowledge. There are on the other hand buttloads of people available that can drive average sized MySQL installations for cheap money.

That's a circular argument: everybody uses MySQL because everyone else does. (I can name a certain OS that benefits from this situation...) A good DBA would have no problem picking up PostgreSQL in a matter of days. I don't care about trained monkeys.

There is no readily available workforce that has actual Postgresql knowledge. There are on the other hand buttloads of people available that can drive average sized MySQL installations for cheap money.

Again bullshit. PostgreSQL supports multiple databases per server very well, including separate access controls for each db.

Postgresql replication is regarded mostly experimental and is not properly integrated with the server. In larger MySQL deployments, replication is often used for load sharing (direct read only queries against any replica), and for backups.

Replication (in both MySQL and PostgreSQL) is mostly useless since it is asynchronous. That is, when you commit a transaction you can not be sure if/when it gets propagated to the slaves. Therefore, if you read from a slave you can never be sure that it's up to date. I'll grant you that there are certain situations where this can be tolerated, but for high availability mission critical sites, it's useless. For that you need distributed transactions. The only open source DB that supports them is firebird.

BTW, I'm glad you mentioned backups. PostgreSQL , just like any real database, can do on-line backups. However, to back up MySQL, you need to read-lock all the tables! The only way to get around that is by setting up replication and backing up the slave.

Postgresql already has many features MySQL either just got with 4.1 or is planned to get in 5.x. That is useless, though, if you do not need these features, but need to deploy in a hosted standard environment, relying on the available workforce.

Yeah, I'm sure you don't need transactions, subselects, triggers, stored procedures, or even *gasp* correct and predictable behaviour.

But you are right about one thing: everybody uses MySQL because everybody else does.

There is a new LAMP: Linux, Apache, Magic, PostgreSQL

By my expirience PgSQL helps to scale your magic while MySQL rather prevents it from happening. ;-)

"Now check out this PostgreSQL stuff, where you get something for nothing."

Things are tight fisted because Sun wants a solid, CONSISTANT platform. This was a MAJOR REASON for the lawsuit that they fought and WON against Microsoft and their VM implementation

And, open-source software would be inconsistent because.......?

Inconsistent, like Apache?

or, perhaps, MySQL?

I get it. You mean inconsistent like this, this, or this?

Oh, the above aren't languages, like php or perl?

Eh, wait a minute. These are all *successful* projects, that are consistent?

If Sun were to open Java sources, it would be trivial to introduce a license (EG: GPL) that would largely offset forking of the codebase. Their best bet would be to pull a "QT" - open the source as GPL, then sell commercial licenses.

I hope this helps: http://www.postgresql.org/docs/7.3/interactive/cli ent-authentication.html#AUTH-PG-HBA-CONF (scroll down to the examples part..)

What you want is this:
local all all md5
host all all 127.0.0.1 255.255.255.255 md5

For CRM, we use TUTOS.

For accounting, it's SQL-Ledger. Both the CRM and accounting apps are backed by PostgreSQL.

For office suites, OpenOffice.

Web browsing is Mozilla; e-mail is whatever our employees prefer (Mozilla, Kmail, Evolution, Pine, Mutt, whatever...)

We are completely MSFT-free and intend to stay that way.

If you're using PostgreSQL, Gedafe is a very nice automatic web frontend generator. Just define your tables, views, constraints, etc. for validation and such, and it takes care of the rest. Give it a try, it's really good.

The author might not read /.
Send him your comment directly if you want him to read it.

"If you re-read my post, you'll realize that my point was not to target specific features of PostgreSQL, but rather to bring attention to some examples that were glossed over by the PostgreSQL zealots a couple of years ago"

Actually, the 8K row limit was well-documented. Checking archives of the PostgreSQL mailing list confirms that there were many posts about it, prior to PostgreSQL 7.1 (released in early 2001) which removed the limit. In fact, there is a web page, PostgreSQL Limits, located just 2 clicks off the main PostgreSQL site, which spelled out these limits. This page has been there for years, as verified by the Wayback Machine.

Further, the need to reguarly vacuum databases hasn't (and isn't not) glossed over. It's well-documented, listed in numerous FAQs and tuning guides, and comes up all the time in #postgresql on openproject.net.

I'm really not sure where you got the idea that these aspect of PG (one of which was removed over 2 years ago) were "glossed over." Nor do I see what relevance they have today.

"If you re-read my post, you'll realize that my point was not to target specific features of PostgreSQL, but rather to bring attention to some examples that were glossed over by the PostgreSQL zealots a couple of years ago"

Actually, the 8K row limit was well-documented. Checking archives of the PostgreSQL mailing list confirms that there were many posts about it, prior to PostgreSQL 7.1 (released in early 2001) which removed the limit. In fact, there is a web page, PostgreSQL Limits, located just 2 clicks off the main PostgreSQL site, which spelled out these limits. This page has been there for years, as verified by the Wayback Machine.

Further, the need to reguarly vacuum databases hasn't (and isn't not) glossed over. It's well-documented, listed in numerous FAQs and tuning guides, and comes up all the time in #postgresql on openproject.net.

I'm really not sure where you got the idea that these aspect of PG (one of which was removed over 2 years ago) were "glossed over." Nor do I see what relevance they have today.

Even better, pgsql-performance

One of the biggest problems with MySQL that so many people complain about is that the entire design philosophy is not one that supports data integrity. Take a look at the list of MySQL Gotchas for starters.

The reason that it's satisfactory for slashdot is the same reason that it became popular in the first place. It was one of the first freely available database servers, and it had particularly fast benchmark results for situations that required lots of selects and not many updates. (I might be slightly wrong about the details, so someone correct me if necessary.) The fast-select advantage made it a popular option for websites a few years ago, because they involve just that. Lots of page-views (selects) and not many updates.

On the other hand, the integrity aspect of MySQL makes it a pain to code for. The MySQL credo seems to be that if input doesn't make sense, then try to guess what was meant and don't report it. (eg. Inserting a null instead of reporting an error.) Furthermore, the MySQL parser recognises certain parts of SQL syntax that are ignored, and (again) not reported. Instead, it just doesn't do anything and pretends that it all worked.

So instead of being able to rely on constraints set in the database, as can be done with nearly any other well-used database, it's necessary to put large amounts of integrity-checking code for things as simple as making sure that dates are the correct format. In some ways it's more like a half-built SQL interface to a regular file system than a database, with features for data integrity hacked on here and there if you know how to use them and always use them correctly.

In slashdot's case, don't be surprised if a random comment goes missing every now and again, because the integrity support just isn't there without complicated overhead work that induces possible mistakes. Slashdot can get away with losing bits and pieces of data, but that's not usually the case. If I say that I want to put some data in the database and that it must meet specific rules, it should either put it in or result in an error. MySQL doesn't do this reliably.

MySQL now seems to be living only on it's fast reputation that it had in the past, driven by people who've heard that it's good and it's fast, but don't know the details. By now, other free databases (postgresql in particular) have caught up a lot, and should be preferable in most cases if you're starting from scratch.

It doesn't have as many features as PostgreSQL and isn't true open source as PostgreSQL.

PostgreSQL isn't owned by one company. The latest release (7.4.1) of PostgreSQL was released a few days ago.

Enjoy :-)

Have they fixed the most serious bug from the 4.x line yet? This makes MySQL versions greater than 3.x utterly useless for many people.

I realize and reaffirm that it is wholly their right to license their software however they like, but would it really be so awful for them to make the client library LGPL?

Ah, well... just another reason to use a better database instead. ;)

Yes.

InnoDB takes a snapshot in time with REPEATABLE READ (and doesn't lock anything to do so). That means you can not get any one elses data injected while you are inside your transaction, which means you get a snapshot of only completed transactions. Here is a link where the creator of InnoDB talks about using mysqldump.

It sounds like PostgreSQL's SERIALIZABLE is very similar to InnoDB's REPEATABLE READ setting. It might be because PostgreSQL isn't really serializable in the mathmatical sense while InnoDB is. I'm not that familar with PostgreSQL's internals to know if it is similar to InnoDB's REPEATABLE READ level.

Server-side user defined functions can be written in several languages: C SQL PL/pgSQL (very similar to Oracle's PL/SQL) Tcl Perl Python (alpha) Ruby

... Yes, GNOME and PostgreSQL are pure GPL apps ...

PostgreSQL is released under the BSD licence.

Just to avoid confusion, Postgresql is released
under a BSD license.

Just to avoid confusion, Postgresql is released
under a BSD license.

Access has the most overhead according to this.

Here's a link to a discussion where the poster states that Access is not good for large installations...

You might check with IBM (DB2), Oracle, MySQL, or Postgres for help as well...I'm sure they'ld be more than happy to help.

Cross platform compatability. Students with Windoze, Linux, or Macs can run most SQL servers...not so with Access...

And then there's the corporate settings...most companies are using DB2, Oracle, MySql, or something that is ANSI-SQL compatible...not M$ SQL...

You also have more utilities and help available for SQL than Access...

There's GUI tools, schema browsers, etc all available for SQL...

If your school runs its website on a *NIX server, you could up-play the compatibility angle...you know, senior projects and such...

One major advantage of SQL is that all of the companies/organizations that I mentioned are free or have a free educational version...I doubt M$ does...

all that is left to make slashcode usuable is to upgrade the database to a real database and re-write the code in a real programing language.

Can you give some benchmarks of when Innodb would be slower than Postgresql?

Actually, the problem isn't so much that you can point a finger at Innodb. Having said that, Innodb is slower than straight up MySQL tables. Aside from that, you need to remember that it's the overall design that's making the difference. PostgreSQL implements a scheme called versioning which greatly reduces the amount of table locking required (see mvcc for more information and explanation). Interestingly enough, this is very simular to what Oracle uses. Beyond that, PostgreSQL has an excellent caching mechanism which greatly helps reduce disk I/O.

No matter how fast you can access your tables, if you can't effectively determine a plan to access your tables, you're going to be slow. PostgreSQL has an excellent optimizing query planner. MySQL has nothing like it. This means that if you use queries which are more than, "select * from foo ;", and have more than a couple of rows worth of data, or multiple indexes (multiple data paths) a query planner is probably going to be important to you. Furthermore, PostgreSQL's planner is highly tunable and the query plans are easily obtainable (for review, validation and optimization). Furthermore, the query planner even supports a genetic algorithm to aid optimizing data path access in even the most bizzar of production query requirements (see GA link for more information). To boot, the planner fully understands virtual I/O, physical I/O, indexes, various join types and algorithms, and is able to grok very complex queries fairly well. This is not to say it's perfect. It's not. Just the same, this feature alone is head and shoulders above MySQL. This is why tables joins is often an problem for MySQL's performance.

Is the scalability jokes you refered to, uses innodb?

Please keep in mind that I was being overly cynical. Just the same, most performance benchmarks which attempt to put MySQL in good light, attempt to minimize the use of Inno tables. The reason being, inno tables impose a performance hit because of the extra features (transactions, etc). Because of this, tests often attempt to NOT use innodb tables unless the test is specifically in place to validate transactional support and associated features. This means, that MySQL almost always looks wicked fast unless data validity is important to you. If it is, you take a performance hit. In both cases, hope you don't have to read and write data at the same time in the same tables. If you do, the table locking will shoot you in the foot. This, for both native and inno tables.

Can you give some example of what makes Postresql more scalable, beside being more sql compliant or closer to a "read rdbms"?

Well, being more SQL compliant really doesn't make it scalable. It's nice and all, but it doesn't do anything for scalability. It does, however, allow you to leverage generalize SQL expertise much more easily. Which, in turn, can translate to better performance.

Let's talk a little bit about performance and scalability. Performance is generally measured in the latency of asking for a result and the time it takes to get a *complete* result back. I stress complete here because somes tests improperly measure. In some cases, some RDBMS will attempt to start returning result sets VERY quickly in order to give the illusion that it's latency is very low, however, the total time for the operation is much, much higher. Thusly, we'll say time for a *complete* result set. In most cases, a partial result set is worthless or out of context until all of the data is available for analysis.

Scalability, on the other hand, is the ability to continue to delivery timely (low latency) results as the load increases. For a typical DB, load generally means inserts, updates and deletes, however, specific workload

Can you give some benchmarks of when Innodb would be slower than Postgresql?

Actually, the problem isn't so much that you can point a finger at Innodb. Having said that, Innodb is slower than straight up MySQL tables. Aside from that, you need to remember that it's the overall design that's making the difference. PostgreSQL implements a scheme called versioning which greatly reduces the amount of table locking required (see mvcc for more information and explanation). Interestingly enough, this is very simular to what Oracle uses. Beyond that, PostgreSQL has an excellent caching mechanism which greatly helps reduce disk I/O.

No matter how fast you can access your tables, if you can't effectively determine a plan to access your tables, you're going to be slow. PostgreSQL has an excellent optimizing query planner. MySQL has nothing like it. This means that if you use queries which are more than, "select * from foo ;", and have more than a couple of rows worth of data, or multiple indexes (multiple data paths) a query planner is probably going to be important to you. Furthermore, PostgreSQL's planner is highly tunable and the query plans are easily obtainable (for review, validation and optimization). Furthermore, the query planner even supports a genetic algorithm to aid optimizing data path access in even the most bizzar of production query requirements (see GA link for more information). To boot, the planner fully understands virtual I/O, physical I/O, indexes, various join types and algorithms, and is able to grok very complex queries fairly well. This is not to say it's perfect. It's not. Just the same, this feature alone is head and shoulders above MySQL. This is why tables joins is often an problem for MySQL's performance.

Is the scalability jokes you refered to, uses innodb?

Please keep in mind that I was being overly cynical. Just the same, most performance benchmarks which attempt to put MySQL in good light, attempt to minimize the use of Inno tables. The reason being, inno tables impose a performance hit because of the extra features (transactions, etc). Because of this, tests often attempt to NOT use innodb tables unless the test is specifically in place to validate transactional support and associated features. This means, that MySQL almost always looks wicked fast unless data validity is important to you. If it is, you take a performance hit. In both cases, hope you don't have to read and write data at the same time in the same tables. If you do, the table locking will shoot you in the foot. This, for both native and inno tables.

Can you give some example of what makes Postresql more scalable, beside being more sql compliant or closer to a "read rdbms"?

Well, being more SQL compliant really doesn't make it scalable. It's nice and all, but it doesn't do anything for scalability. It does, however, allow you to leverage generalize SQL expertise much more easily. Which, in turn, can translate to better performance.

Let's talk a little bit about performance and scalability. Performance is generally measured in the latency of asking for a result and the time it takes to get a *complete* result back. I stress complete here because somes tests improperly measure. In some cases, some RDBMS will attempt to start returning result sets VERY quickly in order to give the illusion that it's latency is very low, however, the total time for the operation is much, much higher. Thusly, we'll say time for a *complete* result set. In most cases, a partial result set is worthless or out of context until all of the data is available for analysis.

Scalability, on the other hand, is the ability to continue to delivery timely (low latency) results as the load increases. For a typical DB, load generally means inserts, updates and deletes, however, specific workload

See also A Brief History of PostgreSQL

Anyone who needs to use COUNT() is completely out of luck. Can't use PgSQL. This problem has not been fixed in the latest release:

From http://www.postgresql.org/docs/7.4/static/function s-aggregate.html
Users accustomed to working with other SQL database management systems may be surprised by the performance characteristics of certain aggregate functions in PostgreSQL when the aggregate is applied to the entire table (in other words, no WHERE clause is specified). In particular, a query like

SELECT min(col) FROM sometable;

will be executed by PostgreSQL using a sequential scan of the entire table.

Meaning horrendously slow for large tables. "Replication", "Enterprise features" when basic stuff like this is broken. This is a shame

To this day, the only reason I don't advocate postgresql at our company right now, is that vacuum doesn't recover index space.

Make free space map efficiently reuse empty index pages, and other free space management improvements

In previous releases, B-tree index pages that were left empty because of deleted rows could only be reused by rows with index values similar to the rows originally indexed on that page. In 7.4, "VACUUM" records empty index pages and allows them to be reused for any future index rows.

An example in the Postgresql 7.4 documentation on the vacuum command shows the new lines of output:

The following is an example from running VACUUM on a table in the regression database:

regression=# VACUUM VERBOSE ANALYZE onek;
INFO: vacuuming "public.onek"
INFO: index "onek_unique1" now contains 1000 tuples in 14 pages
DETAIL: 3000 index tuples were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.01s/0.08u sec elapsed 0.18 sec.
[...]

We have tables with 90% daily turnover, and without daily reindexes, those indexes reach gigs if we don't catch them. Regardless of any improvements, I will continue to suggest against Postgresql until that little problem is fixed.

To this day, the only reason I don't advocate postgresql at our company right now, is that vacuum doesn't recover index space.

Make free space map efficiently reuse empty index pages, and other free space management improvements

In previous releases, B-tree index pages that were left empty because of deleted rows could only be reused by rows with index values similar to the rows originally indexed on that page. In 7.4, "VACUUM" records empty index pages and allows them to be reused for any future index rows.

An example in the Postgresql 7.4 documentation on the vacuum command shows the new lines of output:

The following is an example from running VACUUM on a table in the regression database:

regression=# VACUUM VERBOSE ANALYZE onek;
INFO: vacuuming "public.onek"
INFO: index "onek_unique1" now contains 1000 tuples in 14 pages
DETAIL: 3000 index tuples were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.01s/0.08u sec elapsed 0.18 sec.
[...]

We have tables with 90% daily turnover, and without daily reindexes, those indexes reach gigs if we don't catch them. Regardless of any improvements, I will continue to suggest against Postgresql until that little problem is fixed.

"Create native Win32 port" is one of three "urgent" items on the PostgreSQL to-do list, and Bruce Momjian publishes a detailed status report on the ongoing work. No one on earth can tell you when the work will be complete.

"Create native Win32 port" is one of three "urgent" items on the PostgreSQL to-do list, and Bruce Momjian publishes a detailed status report on the ongoing work. No one on earth can tell you when the work will be complete.

that's been in since 7.2,

Release date: 2002-02-04

In the PostgreSQL FAQ, PostgreSQL is pronounced Post-Gres-Q-L.

Cursors are supported now. Nic Ferrier wrote a patch for this back in April, and I think it got applied in the beginning of May. There's a trick I can't remember right now to enable it (maybe setting the result set type/scrollability first with JDBC2 methods), since it's not quite as efficient for smaller queries. I'm sure the people on the pgsql-jdbc mailing list would help you if you can't figure it out.

Keep in mind that the JDBC drivers shipping with any given version of PostgreSQL are likely not the best available drivers to use with that version. The JDBC people don't make changes to the release branches, unless they started recently. The best available drivers tend to be the ones from their website or in CVS HEAD.

Also, if you stumble on a page listing the compliance features/misfeatures of PostgreSQL, it's hopelessly out of date. I hope they're not still linking to it. The picture is much brighter than what that page suggests.

> Does PostgreSQL have a good GUI component for direct database manipulation?

Traditionally, this has been the job of third party developers. SQL Server is the one exception as it tries to make you dependent on the GUI tools. Still, if you want a GUI tool, both pgAdmin and my own DataDino are good alternatives.

Several. Take your pick. (Check the administrative link off the nav, and also look through the developer tools.)

I understand that PostgreSQL requires cygwin to run on a Windows platform. Since my company is a Windows shop for now (I have not yet been able to convince them to move to Linux) this is an important issue for me. How big of a performance hit is there for running through the cygwin interface? In other words, is PostgreSQL faster than MySQL in Windows?

Can't help you here, I've never done it. Sorry.

Are there plans to go to a native Windows platform?

Yes. There are technical hurdles, but it is actively being worked on. Check out the list, if you're interested.

w

Several. Take your pick. (Check the administrative link off the nav, and also look through the developer tools.)

I understand that PostgreSQL requires cygwin to run on a Windows platform. Since my company is a Windows shop for now (I have not yet been able to convince them to move to Linux) this is an important issue for me. How big of a performance hit is there for running through the cygwin interface? In other words, is PostgreSQL faster than MySQL in Windows?

Can't help you here, I've never done it. Sorry.

Are there plans to go to a native Windows platform?

Yes. There are technical hurdles, but it is actively being worked on. Check out the list, if you're interested.

w

Huh?

ERServer was released open source months ago. Check out GBorg for more information.

And why do YOU need raw disk access? The PostgreSQL developers belive (and rightly I think) that the operating system can do the caching better than they can. Why re-write the wheel? Operating systems have came a long way in the last 10 or 12 years. Days of slow access to the disk are long gone.

BWP

According to the list of supported platforms, it doesn't.

See eRServer on GBorg

Jan Wieck is also just in the process of re-writing replication based on the experiences of eRServer, again, as an OSS project, and it can be viewed at:

Slony-1 on GBorg

See eRServer on GBorg

Jan Wieck is also just in the process of re-writing replication based on the experiences of eRServer, again, as an OSS project, and it can be viewed at:

Slony-1 on GBorg

Plain VACUUM (without FULL) simply reclaims space and makes it available for re-use. This form of the command can operate in parallel with normal reading and writing of the table, as an exclusive lock is not obtained. VACUUM FULL does more extensive processing, including moving of tuples across blocks to try to compact the table to the minimum number of disk blocks. This form is much slower and requires an exclusive lock on each table while it is being processed.

I use PostgreSQL extensively, and I have had a hard time convincing my-mySQL (I'm so clever) exclusive friends to give it a try.

One thing that should be noted is that the JDBC drivers (http://jdbc.postgresql.org) are now among the best I've used. For those developing Java apps, the choice is now even more clear.

Open Office doesn't quite meet requirements either since it doesn't have a DB component. (Or does it? From what I can tell it has DB access components and a GUI to use them, but no actual DB backend.)

MySQL is available for at least Linux, *BSD, and Microsoft Windows operating systems. Do the typical applications of Microsoft Access and its Jet engine really need true ACID guarantees, which MySQL is historically poor at? If so, SAP DB runs on Linux and Windows as well. PostgreSQL runs on Linux and *BSD, and the team is working on a Windows backend.

even those companies have to do buisness with companies that send them PowerPoint presentations detailing important information or information sent as spreadsheets that contain important macros.

My copy of OpenOffice.org suite read a PowerPoint document perfectly.

Until Star Office can flawlessly import every Microsoft Office document ever created (and yes, not even Microsoft Office can do that), no buisness is going to switch - they stand to lose too much existing work.

Once Microsoft EOLs old versions of MS Office, corporate customers will look for a replacement. As you admit, MS Office can't always import previous versions' documents perfectly, and Word takes a lot of formatting cues from the default printer rather than from the document, so if StarOffice does it just as well, it'll win on price.

NEXT!

1. it was undocumented
   
2. it was poorly named
   
3. it was crufty: the unused OID argument is intended to workaround an optimizer bug that has been fixed for years
   
4. it didn't play nicely with other portions of the backend that also use a PNRG.