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

PostgreSQL 14

postgresql.org

Post reply on HN
Print view View original

201–210 of 293 posts

Re: PostgreSQL 14

#201

Post by outworlder »

polskibus wrote: post #142
hyper_reality wrote: post #46

Earlier quoted context omitted.

It would increase disk usage by a significant amount, since transaction IDs appear twice in tuple headers (xmin/xmax). Essentially they are overhead on every database row. This submission has a discussion on it: https://news.ycombinator.com/item?id=19082944

I wonder how does MS SQL work differently.

It has a similar concept if you need MVCC (with InnoDB). It also has a concept of transaction IDs. And also need to clean them up (purge). They will both have table bloat if not done.

Since details matter, there's a post that explains it far better than I could:

https://www.enterprisedb.com/blog/mysql-vs-postgresql-part-2...

Re: PostgreSQL 14

#202

Post by polskibus »

outworlder wrote: post #201
polskibus wrote: post #142

Earlier quoted context omitted.

I wonder how does MS SQL work differently.

It has a similar concept if you need MVCC (with InnoDB). It also has a concept of transaction IDs. And also need to clean them up (purge). They will both have table bloat if not done. Since details matter, there's a post that explains it far better than I could: https://www.enterprisedb.com/blog/mysql-vs-postgresql-part-2...

I asked about MS not My though.

Re: PostgreSQL 14

#203

Post by The_Colonel »

mayankkaizen wrote: post #184
salil999 wrote: post #155

Earlier quoted context omitted.

And how exactly is that a problem?

That was sarcasm. But yeah, you can search for MongoDB and you'll come across many many posts criticizing it. It can be said Mongodb is hated ad much as Postgres is loved. Personally I have no opinion about mongodb.

Yes, and most of these love/hate memes are blowned out of proportion by people who don't actually have any real expertise in those technologies, but just parrot whatever they've read in some memes.

Re: PostgreSQL 14

#204

Post by foresto »

idoubtit wrote: post #187
throw0101a wrote: post #149

Earlier quoted context omitted.

> wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add - Is there a reason to do this rather than putting the key in /etc/apt/trusted.gpg.d/?

Putting the key in /etc/apt/trusted.gpg.d/ gives it too much power over all the repositories. A malicious (maybe compromised) third party repository could publish a package that replace an official Debian package. So trusted.gpg.d/ is not the recommended method. For more information, see the official Debian wiki which states "The key MUST NOT be placed in /etc/apt/trusted.gpg.d" https://wiki.debian.org/DebianReposito…

And while you're there, pay attention to the signed-by option. It's what allows you (the admin) to limit APT's trust in the keys you add.

Re: PostgreSQL 14

#205

Post by sigmonsays »

jd_mongodb wrote: post #200
tpxl wrote: post #195

Earlier quoted context omitted.

Some things seem to have changed from 2018, but MongoDB was by far the worst database I ever had the displeasure of using (and Amazon DocumentDB was even worse). https://jepsen.io/analyses/mongodb-3-6-4 https://jepsen.io/analyses/mongodb-4.2.6

Posting old Jepssen analyses is like pointing at old bug reports. Everytime Jepsen finds a bug we fix it lickety-split. I know it's not cool to focus on that fact, but it is a fact. The Jepsen tests are part of the MongoDB test suite so when we fix those problems they stay fixed. I would love to hear your personal experience of MongoDB as opposed to reposting old Jepsen reports. Perhaps there is something that we can…

where is the latest jepsen test results published?

Re: PostgreSQL 14

#206

Post by mixmastamyk »

mypastself wrote: post #86
mixmastamyk wrote: post #77

Earlier quoted context omitted.

Happy with dbeaver, what are its shortcomings re pg?

I guess I’m still getting used to it, but it always takes a few extra steps to open things like views and functions, autocomplete needs configuring to work properly, and a couple of other features I’m blanking on at the moment. It’s all small stuff, but it can add up.

Yes, they are in separate folders, but don't think it has to do with PG per se. My autocomplete works well, don't think I did anything special. Maybe added a schema to the "search path?" May have been pgcli (which I also recommend).

Re: PostgreSQL 14

#207

Post by nix23 »

jeltz wrote: post #98
skrebbel wrote: post #63

These changes look fantastic. If I may hijack the thread with some more general complaints though, I wish the Postgres team would someday prioritize migration. Like make it easier to make all kinds of DB changes on a live DB, make it easier to upgrade between postgres versions with zero (or low) downtime, etc etc. Warnings when the migration you're about to do is likely to take ages because for some reason it's going…

Migrations are quite highly prioritized in PostgreSQL. PostgreSQL has the by far best migration support of any database I have worked with. There is of course a lot of work left to do but that is true for many other areas in PostgreSQL. Also I can't agree at all with "nobody coded it", patches in this area generally welcome. My first real patch for PostgreSQL was about improving migrations. And there has been talk ab…

> far best migration support of any database I have worked with

BS, have you never worked with mysql or sqlite?

Re: PostgreSQL 14

#208

Post by dijit »

nix23 wrote: post #207
jeltz wrote: post #98

Earlier quoted context omitted.

Migrations are quite highly prioritized in PostgreSQL. PostgreSQL has the by far best migration support of any database I have worked with. There is of course a lot of work left to do but that is true for many other areas in PostgreSQL. Also I can't agree at all with "nobody coded it", patches in this area generally welcome. My first real patch for PostgreSQL was about improving migrations. And there has been talk ab…

> far best migration support of any database I have worked with BS, have you never worked with mysql or sqlite?

MySQL migrations are beyond a joke.

It’s absolutely impossible that you’re not trolling with such a statement.

Re: PostgreSQL 14

#209

Post by nix23 »

skrebbel wrote: post #164
jeltz wrote: post #98

Earlier quoted context omitted.

Migrations are quite highly prioritized in PostgreSQL. PostgreSQL has the by far best migration support of any database I have worked with. There is of course a lot of work left to do but that is true for many other areas in PostgreSQL. Also I can't agree at all with "nobody coded it", patches in this area generally welcome. My first real patch for PostgreSQL was about improving migrations. And there has been talk ab…

Sorry, I didn't mean offense. What I meant with "nobody coded it" is that the migration DX features that don't exist yet, likely don't exist simply because they haven't been made yet (and not because eg they're architecturally impossible or because the postgres team are stupid or sth). Its hard to complain about OSS without attacking the creators, I tried to do that right buy clearly I failed nevertheless :-) Thanks…

>Sorry, I didn't mean offense.

Don't be a SJP, you have the right to offend someone when he talks bs.

Re: PostgreSQL 14

#210

Post by nix23 »

dijit wrote: post #208
nix23 wrote: post #207

Earlier quoted context omitted.

> far best migration support of any database I have worked with BS, have you never worked with mysql or sqlite?

MySQL migrations are beyond a joke. It’s absolutely impossible that you’re not trolling with such a statement.

Copy/hardlink the data-files and start the new engine instead have to make a dump and import it?

It's a joke that you have to make a offline dump and import for upgrades with pgsql.

Post reply on HN