Oracle vs. PostgreSQL: First Glance

Post by davidgerard » Mon, May 04, 2020, 4:33 PM UTC

davio wrote: post #74

I've been at 3 separate companies where each respective CIO had "get rid of Oracle" as a strategic initiative.

Post by ibejoeb » Mon, May 04, 2020, 4:40 PM UTC

da_chicken wrote: post #53

doublesCs wrote: post #26

Earlier quoted context omitted.

Thanks for that link. > Historically we've always materialized the full output of a CTE query Do you know if this means that CTEs are written to disk? I didn't think this was the case. (In the case of materialized views that qualifier means the view is written to disk).

Here "materialization" just means that the query planner treats it as an optimization fence. That means the system doesn't do any optimization between the CTE and the query referencing it. It would prepare the output of the CTE as a completely separate entity essentially as if you had dumped it to a temp table. It may not be written to disk if there was sufficient memory, but either way you're sacrificing any optimiz…

    with mycte as (
        select a, count(b) 
        from foo 
        group by a
    )
    select *
    from mycte
    where a = 10;

    with mycte as (
        select a, count(b) 
        from foo 
        where a = 10;
        group by a
    )
    select *
    from mycte;

Post by tibiahurried » Mon, May 04, 2020, 4:44 PM UTC

ksec wrote: post #59

dtheodor wrote: post #38

Earlier quoted context omitted.

It's very true today. The problem discussed here is performance on complex queries (e.g. subqueries), and the query planner plays a huge role in that. The Postgres query planner has various issues. Here are two recent posts talking about planner issues: https://medium.com/@rbranson/10-things-i-hate-about-postgres... https://www.cybertec-postgresql.com/en/things-could-be-impro... Also JIT compilation, while very nice…

For someone not following closely, What are the reasons behind the lack of work on JIT since then?

Post by pjmlp » Mon, May 04, 2020, 4:55 PM UTC

thda wrote: post #85

pjmlp wrote: post #34

Earlier quoted context omitted.

- A much better developer experience for stored procedures, with proper packaging, compilation to native code, graphical debugger. - RAC and distributed transactions across a database cluster - Integration with APIs - A much better experience in Java and .NET drivers, including SQL custom data types.

> compilation to native code, graphical debugger. You have this on postgresql. > RAC and distributed transactions across a database cluster Needed only in telcos where galera would be enough

Post by [deleted] » Mon, May 04, 2020, 4:57 PM UTC

arethuza wrote: post #21

drchopchop wrote: post #10

Earlier quoted context omitted.

I've spent a fair amount of time at the Sofitel in Redwood Shores, and I'd often chat with Oracle "sales engineers" at the bar. A simple "so, what do you work on" question would inevitably generate an hour's worth of them explaining some convoluted acronym-heavy product with a pushy sales model, and I'd eventually be like "ok... so it's a database?".

To be fair to Oracle (not something I say very often) - I suspect most of their sales are business applications (ERP, CRM, financial) that happen to use their database engine as a back end.