5 ms·

Not my personal experience, but one of my professors is trying to get his patch approved into Postgres for an upcoming release; since his changes are very deep

Not my personal experience, but one of my professors is trying to get his patch approved into Postgres for an upcoming release; since his changes are very deep and touch the kernel (he wants to add support for temporal data) he told me the whole process will take years and the whole community will examine these changes before anything is added. I think that pretty much explains it: Cutting edge features are proposed way earlier than commercial DBs start thinking about implementing them, and the community hones them over years before they are released to the mainstream public.

bunderbunder 8y ago
This mirrors my experience working at a company that achieved similar results on some of its internal products. The very biggest difference between working there and working anywhere else, is that developers spent only a tiny fraction of time actually writing code. The biggest chunk of it was spent on peer review. Every change required sign-off from everyone on the immediate team, and, if it was being made to a component that other teams interacted with, they'd also have members reviewing the changes. And, as a newcomer, I found the reviews to be brutal. Over time, though, I came to recognize that what originally felt like others getting all up in my business about pedantic little variable naming issues was actually everyone having my back about legitimate maintainability concerns. Next biggest chunk was spent on planning - understanding requirements, talking over changes with anyone who might be impacted by them, etc. The second biggest difference was just how fast we could move. I think a lot of that came from a certain "wei wu wei" that was attributable to the deep understanding of the systems we were working on that developed out of all that time with our hands off our keyboards. Allow me the vice of inserting a mangled Hitchhiker's quote here: "If human beings don’t keep exercising their [fingers], he thought, their [hands] probably seize up. After a few months’ consideration and observation he abandoned this theory in favor of a new one. If they don’t keep on exercising their [fingers], he thought, their brains start working."
jeffdavis 8y ago
What is the professor's name?
tomnipotent 8y ago
> Cutting edge features are proposed way earlier than commercial DBs This is not true. SQL Server & Oracle already have pretty every feature just released in 11 and have had most of them for many years.
- orf 8y ago
  Like native JSON support?
  - zeroname 8y ago
    That's a "hipster" feature, not something that the "enterprise" customers of these products are asking for.
    - Twisell 8y ago
      This is quite a pedantic opinion. I’ve found jsonb pretty useful to handle semi-structured data in production. I wouldn’t try to use jsonb attribute in a primary key though (even if it’s practically possible as it’s a fully featured base type).
    - gleenn 8y ago
      Not sure if you're trying to be funny about the hipster thing. I've seen the json features used at multiple serious organizations. It turned what would have otherwise been unnecessarily complicated queries into really reasonable queries in our ETL pipeline.
      - derefr 8y ago
        It's a difference of mindset. Postgres includes many features that increase the number of simple use-cases for the existing data in their database, thus allowing you to replace a Postgres complement (like Mongo) with Postgres for that use-case. "Enterprise" DBMSes like Oracle and MSSQL, meanwhile, don't focus so much on expanding the use-cases of their offering, as they do on expanding the number of ways a sysadmin can take the existing use-cases and make them scale better, with less manual maintenance. Oracle and Microsoft allow you to replace their ecosystem of tools and extensions with a DBMS-internal feature for the given sysadmin need. So Postgres has an expanding ecosystem of tooling and extensions, but is slowly eating its complements; while Oracle and MSSQL have an expanding space of complementary offerings, but are slowly eating their own product ecosystems. Or, to put that another way: Postgres focuses more on making life easier for people who write SQL; Oracle and Microsoft focus more on making life easier for the DBAs who manage the DBMS cluster that people are running SQL against.
manigandham 8y ago
> Cutting edge features are proposed way earlier than commercial DBs start thinking about implementing them Definitely not true. Postgres development is slow, deliberate, and the opposite of cutting edge. It's what has lead to a great platform that is reliable and flexible, but every single commercial database out there has far modern tech implemented.
- Tostino 8y ago
  In some ways that is true, and in others that is not the case. For JSON support, PG really did lead the way as far as RDBMS' go. Things like range types are something I wish MSSQL supported when I used it at my day job.
  - bunderbunder 8y ago
    And plenty more that PostgreSQL will probably lack for the foreseeable future. Especially at the more expensive pricing tiers. But I'm not sure it's a fair comparison, precisely because of that word, "pricing". It's amazing what you can get people to do when you're paying them big bucks to do it. Part of what makes PostgreSQL so impressive is what it does given the budget it's working with.
  - riku_iki 8y ago
    I think they targeted xml instead of json, and much earlier. XML is much more enterprise-ly.
dominotw 8y ago
> support for temporal data native support for TimescaleDB ? That would be nice.
- derefr 8y ago
  TimescaleDB is for time-series data, which is half-way to being one kind of temporal data. Full support for both kinds of temporal data ("valid time" and "transaction time") requires a bit more engineering. The PG support for the TSTZRANGE data type, operators built on it, and indices built on those operations, was part of a previous phase of adding support for "valid time" temporal data. https://pgxn.org/dist/temporal_tables/ https://pgxn.org/dist/temporal_tables/ is an extension implementing a prototype of "transaction time" temporal data, though in modern Postgres, you can do this much yourself. In both cases, none of the SQL syntax specific to temporal queries has been implemented yet. Rather than a distinct view and backing "current" and "history" tables and etc., you should be able to just have a table that represents all of those things, and do queries on its components using different syntax. (Sort of like how S3 versioned bucket resources work.)

bunderbunder 8y ago

This mirrors my experience working at a company that achieved similar results on some of its internal products. The very biggest difference between working there and working anywhere else, is that developers spent only a tiny fraction of time actually writing code. The biggest chunk of it was spent on peer review. Every change required sign-off from everyone on the immediate team, and, if it was being made to a component that other teams interacted with, they'd also have members reviewing the changes. And, as a newcomer, I found the reviews to be brutal. Over time, though, I came to recognize that what originally felt like others getting all up in my business about pedantic little variable naming issues was actually everyone having my back about legitimate maintainability concerns. Next biggest chunk was spent on planning - understanding requirements, talking over changes with anyone who might be impacted by them, etc. The second biggest difference was just how fast we could move. I think a lot of that came from a certain "wei wu wei" that was attributable to the deep understanding of the systems we were working on that developed out of all that time with our hands off our keyboards. Allow me the vice of inserting a mangled Hitchhiker's quote here: "If human beings don’t keep exercising their [fingers], he thought, their [hands] probably seize up. After a few months’ consideration and observation he abandoned this theory in favor of a new one. If they don’t keep on exercising their [fingers], he thought, their brains start working."

jeffdavis 8y ago

What is the professor's name?

tomnipotent 8y ago

> Cutting edge features are proposed way earlier than commercial DBs This is not true. SQL Server & Oracle already have pretty every feature just released in 11 and have had most of them for many years.

orf 8y ago
Like native JSON support?
- zeroname 8y ago
  That's a "hipster" feature, not something that the "enterprise" customers of these products are asking for.
  - Twisell 8y ago
    This is quite a pedantic opinion. I’ve found jsonb pretty useful to handle semi-structured data in production. I wouldn’t try to use jsonb attribute in a primary key though (even if it’s practically possible as it’s a fully featured base type).
  - gleenn 8y ago
    Not sure if you're trying to be funny about the hipster thing. I've seen the json features used at multiple serious organizations. It turned what would have otherwise been unnecessarily complicated queries into really reasonable queries in our ETL pipeline.
    - derefr 8y ago
      It's a difference of mindset. Postgres includes many features that increase the number of simple use-cases for the existing data in their database, thus allowing you to replace a Postgres complement (like Mongo) with Postgres for that use-case. "Enterprise" DBMSes like Oracle and MSSQL, meanwhile, don't focus so much on expanding the use-cases of their offering, as they do on expanding the number of ways a sysadmin can take the existing use-cases and make them scale better, with less manual maintenance. Oracle and Microsoft allow you to replace their ecosystem of tools and extensions with a DBMS-internal feature for the given sysadmin need. So Postgres has an expanding ecosystem of tooling and extensions, but is slowly eating its complements; while Oracle and MSSQL have an expanding space of complementary offerings, but are slowly eating their own product ecosystems. Or, to put that another way: Postgres focuses more on making life easier for people who write SQL; Oracle and Microsoft focus more on making life easier for the DBAs who manage the DBMS cluster that people are running SQL against.

manigandham 8y ago

> Cutting edge features are proposed way earlier than commercial DBs start thinking about implementing them Definitely not true. Postgres development is slow, deliberate, and the opposite of cutting edge. It's what has lead to a great platform that is reliable and flexible, but every single commercial database out there has far modern tech implemented.

Tostino 8y ago
In some ways that is true, and in others that is not the case. For JSON support, PG really did lead the way as far as RDBMS' go. Things like range types are something I wish MSSQL supported when I used it at my day job.
- bunderbunder 8y ago
  And plenty more that PostgreSQL will probably lack for the foreseeable future. Especially at the more expensive pricing tiers. But I'm not sure it's a fair comparison, precisely because of that word, "pricing". It's amazing what you can get people to do when you're paying them big bucks to do it. Part of what makes PostgreSQL so impressive is what it does given the budget it's working with.
- riku_iki 8y ago
  I think they targeted xml instead of json, and much earlier. XML is much more enterprise-ly.

dominotw 8y ago

> support for temporal data native support for TimescaleDB ? That would be nice.

derefr 8y ago
TimescaleDB is for time-series data, which is half-way to being one kind of temporal data. Full support for both kinds of temporal data ("valid time" and "transaction time") requires a bit more engineering. The PG support for the TSTZRANGE data type, operators built on it, and indices built on those operations, was part of a previous phase of adding support for "valid time" temporal data. https://pgxn.org/dist/temporal_tables/ https://pgxn.org/dist/temporal_tables/ is an extension implementing a prototype of "transaction time" temporal data, though in modern Postgres, you can do this much yourself. In both cases, none of the SQL syntax specific to temporal queries has been implemented yet. Rather than a distinct view and backing "current" and "history" tables and etc., you should be able to just have a table that represents all of those things, and do queries on its components using different syntax. (Sort of like how S3 versioned bucket resources work.)