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

New in PostgreSQL 10

wiki.postgresql.org

Post reply on HN
Print view View original

251–258 of 258 posts

Re: New in PostgreSQL 10

#251

Post by wiz21c »

dsr_ wrote: post #233
wiz21c wrote: post #214

Earlier quoted context omitted.

>> I think most Oracle installs are from the days ram was limited Could you explain ? Personally I use Oracle (and hopefully one day PG) because it gives me guarantees on data integrity and these guarantees help me to think about my programs more easily.

Oracle started before microcomputers (PCs) were anything but toys. In 1983, they were multiplatform: mainframes and minicomputers. a 1983 minicomputer might have 2 CPUs, each good for 2 MIPS, 8 MB of RAM and primary storage of as much as a gigabyte or two of disks. In the early 2000s, a serious database machine -- say, a Sun E10000 - had up to 64 CPUs, running at 400-500MHz each, 64 GB of RAM, and a huge cabinet full…

>>> Oracle started before microcomputers (PCs) were anything but toys.

I didn't know that. At that time I was discovering Applesoft basic :-)

Re: New in PostgreSQL 10

#252

Post by vetinari »

manigandham wrote: post #163
striking wrote: post #160

Earlier quoted context omitted.

Debian and derivatives have it in repos by default. Please don't make claims like those.

That's more to do with the OS than the DB, and many repo entries are outdated. MSSQL hasnt existed on Linux before, but either way: > I'm surprised at how many people seem to have taken issue with a simple comment.

It's not that the OS supplied versions are outdated. They are updated whenever a minor release comes out.

The thing is, that you must migrate your database between major pgsql releases and you don't want your distro to force it on you. The community pgsql repo has the same rules - you have separate repo for each major release, so no surprises either.

Re: New in PostgreSQL 10

#253

Post by ww520 »

takeda wrote: post #228
ww520 wrote: post #169

Earlier quoted context omitted.

DRBD's replication is synchronous. That means the block device's write() call on the primary won't return until the data is written onto the standby's disk. It's is as strong a guarantee as you can get. In case of the secondary not available, the data are queued up in the primary and sync up with the secondary when it comes back online. If the primary's disk is destroyed at that time, the failure case and data loss i…

I guess that's better, but it would just decrease performance. I still think using binlogs is safer and more efficient though, since it transfers only what's needed to make an update.

Performance is the same if not better than database level replication. The database level replication is synchronous too and have to wait for the standby db to finish writing. If it's async, it has a worse data loss problem.

The DRBD replication is fast because it intercepts the write call and then issues the network send and writing to the underlying disk in parallel. Gigabit or 10G network IO are magnitudes faster than disk seek/write. The write to disk on the standby server can happen in parallel as the primary's write to underlying disk.

Re: New in PostgreSQL 10

#254

Post by [deleted] »

grzm wrote: post #234
bjt wrote: post #172

Earlier quoted context omitted.

Perhaps I'm missing something, but your description doesn't seem consistent with my understanding of the index-only scan feature that's been in PG since 9.2 https://wiki.postgresql.org/wiki/Index-only_scans

Yes, you're right about index-only scans, in the sense that the data in the indexed columns can be used in some cases. As I understand it, indexed organized tables goes further than that in that row data for non-indexed columns is also included.

[deleted]

Re: New in PostgreSQL 10

#255

Post by mst »

ibotty wrote: post #175
mst wrote: post #124

Earlier quoted context omitted.

You're talking about DDL. They're talking about an in-place rewrite of the value of a single column, which, yes, InnoDB will do with way less write load than postgresql.

Can you provide specifics? AFAICT that applies only to indexes (where there is another layer of indirection in MySQL).

InnoDB clusters on disk by PK so if your record is the same width and you don't change the PK it can AFAIK update in-place.

Re: New in PostgreSQL 10

#256

Post by type0 »

irrational wrote: post #154
alceta wrote: post #19

If anyone even remotely involved with the maintenance and development of pg reads this thread - Thank you! - for all your efforts in building and improving a first class product that keeps me amazed at the strides it takes with each major. release.

Truly. We've recently moved from Oracle (after using it for 15 years) to Postgresql. It's like a breath of fresh air. The documentation for Postgres is unbelievably superior to Oracle. So far its performance is equal to or better than Oracle. We had to go through and rewrite thousands of queries, but the sql syntax of Postgres was always simpler and more logical than the equivalent in Oracle (I think Oracle has too m…

Oracle is the real elephant in the room, all pun intended.

Re: New in PostgreSQL 10

#257

Post by gshulegaard »

spullara wrote: post #73
gshulegaard wrote: post #30

Earlier quoted context omitted.

Ultimately it depends on your use case and how much tuning/schema design/explicit management you are willing to do. My team lead did a talk at NGINX Conf 2017 which touched on how we tuned Postgres to handle 1 Billion metrics per day for NGINX Amplify ( https://www.nginx.com/products/nginx-amplify/ ). I would link it, but it seems it hasn't been published by our Conf team yet. We did this on 9.4 so the changes outlin…

CitusData yes but RedShift is the Paraccel backend and just uses the frontend of postgresql.

Hmmm...I thought ParAccel was a derivative of Postgres:

https://wiki.postgresql.org/wiki/PostgreSQL_derived_database...

Re: New in PostgreSQL 10

#258

Post by ibotty »

mst wrote: post #255
ibotty wrote: post #175

Earlier quoted context omitted.

Can you provide specifics? AFAICT that applies only to indexes (where there is another layer of indirection in MySQL).

InnoDB clusters on disk by PK so if your record is the same width and you don't change the PK it can AFAIK update in-place.

Very late answer, but no, that is incompatible with mvcc. How can transactions (and rollbacks) work?
Post reply on HN