Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PostgreSQL is the worlds’ best database

2ndquadrant.com

Post reply on HN
Print view View original

251–260 of 365 posts

Re: PostgreSQL is the worlds’ best database

#251

Post by amaccuish »

al_ak wrote: post #246
AnonymousPlanet wrote: post #241

Earlier quoted context omitted.

Why would you want LDAP integration for a database? Maybe that kind of messed up requirement is part of the problem? One of the bigger issues with places that have made themselves dependent on MS solutions is that MS software completely permeates the place. Then when the pain of going full MS is too big, they are only looking for drop in replacements of existing parts. This will never go well. MS software never plays…

This is very typical in an enterprise shop where you have end users connecting directly to the database for reporting purposes. Being able to take advantage of your existing directory structure and security groups is huge.

Exactly. Why should I have to rewrite a whole ACL infrastructure when I can store it all in one place, and it doesn't matter how you access the database, it's all enforced.

Re: PostgreSQL is the worlds’ best database

#252

Post by anarazel »

thosakwe wrote: post #247

I use Postgres for everything. The one thing I wish they would do, though, is improve the error messages when a query fails. At the very least, if I know which position in the text is the beginning of an error, I can fix it.

> The one thing I wish they would do, though, is improve the error messages when a query fails.

Yea, we definitely need to do better there. But it's harder than one might think initially :(. My suspicion is that we (the PG developers) will have to write our own parser generator at some point... We don't really want to go to a manually written recursive descent parser, to a large part because the parser generator ensuring that the grammar doesn't have ambiguities is very helpful.

> At the very least, if I know which position in the text is the beginning of an error, I can fix it.

For many syntax errors and the like we actually do output positions. E.g.

  postgres[1429782][1]=# SELECT * FROM FROM blarg;
  ERROR:  42601: syntax error at or near "FROM"
  LINE 1: SELECT * FROM FROM blarg;
                        ^
(with a mono font the ^ should line up with the second FROM)

If you have a more concrete example of unhelpful errors that particularly bug you, it'd be helpful. In some cases it could be an easy change.

Re: PostgreSQL is the worlds’ best database

#253

Post by anarazel »

manigandham wrote: post #190
wbl wrote: post #183

Earlier quoted context omitted.

Geoquery. That's a very difficult query to efficiently index: requires learning about WGS84 to get the right answer even for computing the radius.

All of these databases have geospatial data types for efficient querying and indexing. It's been a standard feature for years. Even if they didn't, there are plenty of algorithms based on lat/lon which uses numeric/float data types with simple indexes.

> Even if they didn't, there are plenty of algorithms based on lat/lon which uses numeric/float data types with simple indexes.

Not that trivial if you're not just dealing with points.

Re: PostgreSQL is the worlds’ best database

#254

Post by egeozcan »

nickpeterson wrote: post #221
egeozcan wrote: post #201

Earlier quoted context omitted.

I'd love to see the MERGE statement from MSSQL in other databases. Wonderful tool for integrations.

Merge statement always comes with a bunch of caveats from MSSQL experts, has that changed recently?

It does have a bunch, but all of them are implementation problems, AFAICT. The idea is great though.

Re: PostgreSQL is the worlds’ best database

#255

Post by riku_iki »

pritambarhate wrote: post #188
ggm wrote: post #51

PostgreSQL and ZFS is a marriage made in heaven. Block aligns to disk behaviour, snapshots make great low latency db dumps trivial. Never regretted making the combo

Can you please give us more info about your workload? Is it very high throughput DB? Especially for Inserts and Updates? I searched on ZFS and PostgreSQL performance a couple of years ago on the Internet and popular opinion seems to be databases with Copy on Write type of file systems don't give the best performance.

I am not deep expert, but my impression is that Postgres MVCC is kinda Copy on Write approach already (no in place updates, but you write new page for each update), so it should be perfect marriage..

Re: PostgreSQL is the worlds’ best database

#256

Post by setr »

jfkebwjsbx wrote: post #209
ansible wrote: post #180

Earlier quoted context omitted.

Rust is more complicated than some languages with GC. However, if you are writing some code with multi-threading (who isn't these days), then you may eventually want the help Rust gives you there as far as correctness goes.

Multithreading is only needed in very few fields. Multiprocessing is way easier and works fine for most. And the majority of programmers still only need to write serial code.

And if not serial.. embarrassingly parallel

Re: PostgreSQL is the worlds’ best database

#257

Post by dpc_pw »

stickfigure wrote: post #245

Postgres is my go-to RDBMS, but I do have one serious complaint: Connections are too expensive. This is a side-effect of the old-school one-process-per-connection architecture that Postgres uses. MySQL (ick) easily handles thousands of connections on small servers; with Postgres you will need a LOT of RAM to sustain the same, RAM that would be better served as cache. I've found (at least, for my current app) that the…

It might be possible write a small proxy in Rust, that would run next to a PG instance, accepted connections using `async` and then forwarded queries using some limited size connection pool.

Re: PostgreSQL is the worlds’ best database

#258

Post by 32gbsd »

me551ah wrote: post #56

Having migrated a postgres database to dynamodb, I would say that I'm never going to use postgres again. The problem with all SQL databases is that they are too easy to query and use. You add all kinds of select queries, joins and foreign keys and when traffic hits scramble to make it scale. NoSQL is hard to design but you can atleast be sure that once traffic hits, you don't have to redesign the schema to make it sc…

Some say that scaling is a edge case. what say you?

Re: PostgreSQL is the worlds’ best database

#259

Post by egeozcan »

kardianos wrote: post #227
egeozcan wrote: post #201

Earlier quoted context omitted.

I'd love to see the MERGE statement from MSSQL in other databases. Wonderful tool for integrations.

I've had to personally avoid MERGE statements due to implementation problems in MSSQLServer. One system just updated to 2019, so maybe it is better now. I also have to lookup the syntax each time, but that might be just me.

In some projects the MERGE helped me a lot and in my previous job, all of our integration scripts were merge based. You just learn to avoid the pitfalls, but you're right that it does have some: https://www.mssqltips.com/sqlservertip/3074/use-caution-with...

I'm sure if postgres had it, it wouldn't have had most of those problems.

Re: PostgreSQL is the worlds’ best database

#260

Post by egeozcan »

AnonymousPlanet wrote: post #241
zaat wrote: post #222

Earlier quoted context omitted.

Well, a client invited me to evaluate PostgreSQL. Strong MSSQL shop, thousands of databases, millions of customers, tens thousands internal users. Big pile of licensing money they were eager to save. We investigated the options for LDAP and Kerberos integration, commercial and free. Turns out there is no decent way to do it and grant permissions based on LDAP groups. There wasn't even a a half decent way. The only op…

Why would you want LDAP integration for a database? Maybe that kind of messed up requirement is part of the problem? One of the bigger issues with places that have made themselves dependent on MS solutions is that MS software completely permeates the place. Then when the pain of going full MS is too big, they are only looking for drop in replacements of existing parts. This will never go well. MS software never plays…

LDAP is amazingly convenient. Why not centralize the user/group structure and use it for db access as well?
Post reply on HN