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

PostgreSQL 9.6 Released

postgresql.org

Post reply on HN
Print view View original

41–50 of 136 posts

Re: PostgreSQL 9.6 Released

#41

Post by ngrilly »

rwultsch wrote: post #34
dhd415 wrote: post #20

Earlier quoted context omitted.

>>In InnoDB all the data is stored in the PK while in PG it is just a pointer. This is just a consequence of the PK being a clustered index in InnoDB which has both pros and cons. One of the big cons is that all of the columns of the PK are implicitly added to every secondary index as the row identifier. That isn't a big problem if your PK is a single column int, but if it's multiple columns, that often results in un…

If you don't want a clustered index in InnoDB you can define the primary key as an auto incrementing uint.

Yes, you can, but it doesn't change the fact that you still have a clustered index (an index organized table), which is great for PK lookups, but bad if you do a secondary indexes lookup (because you need to lookup through 2 B-trees instead of 1). There is real, and well-known, tradeoff here.

Re: PostgreSQL 9.6 Released

#43

Post by ris »

jbkkd wrote: post #4

Congratulations to the PostgreSQL Global Development Group on a much-anticipated release. Curious about this: > parallelism can speed up big data queries by as much as 32 times faster Why would it be only 32 times faster? The sky's the limit if there aren't major bottlenecks on the way.

Nothing ever scales linearly without limit.

Re: PostgreSQL 9.6 Released

#44

Post by dragonwriter »

ignoramous wrote: post #7

A tangential question: Everyone speaks about InnoDB and how performant and reliable it is... and multiple firms even use it as a KV-store (Uber/Pinterest/AWS) bypassing MySQL entirely. I have never heard much about storage engines in Postgres, why could this be so? Wikipedia has a (stub) article on InnoDB, but nothing on Postgres' storage engines... just wondering why that is.

> I have never heard much about storage engines in Postgres, why could this be so?

Because PG isn't designed around pluggable storage engines, so its not really as practical to take a storage engine out and use it separately, and doesn't make much sense to talk about the storage engine separately from the whole system.

Re: PostgreSQL 9.6 Released

#46

Post by nhumrich »

mgberlin wrote: post #42

Does anyone know when this will be available on AWS RDS?

Probably in 3-4 months. AWS has historically had a 3 month gap time for postgres. Their policy (from what they have said on the forums at least) is they wait for at least x.x.1 release before they start working on it.

Re: PostgreSQL 9.6 Released

#47

Post by dragonwriter »

Roboprog wrote: post #45

Is it just selection bias from posted links on HN, or has the PostgreSQL team been doing many (feature) releases lately? Sounds good!

> Is it just selection bias from posted links on HN, or has the PostgreSQL team been doing many (feature) releases lately?

I think more like the former -- as I recall, the recent articles have mostly been about specific work going on for the 9.6 release, prereleases of 9.6, and now the actual release of 9.6.

Re: PostgreSQL 9.6 Released

#48

Post by taneliv »

fabian2k wrote: post #17

Just from reading the documentation, the full text search features on Postgres already look pretty powerful. And it is encouraging that they are actively being worked on. I'm wondering how this compares to a dedicated search engine like Solr or Elasticsearch. Are there huge differences in performance, features or search quality? At which scale does using Postgres for full text search still make sense?

Can pgsql fts do stemming or more complex lemmatisation for languages other than English? Or ranking of results based on Okapi BM25 or similar? I was looking into this about two years ago and those were the features in favor of Lucene (basis of ES and Solr).

Re: PostgreSQL 9.6 Released

#49

Post by ngrilly »

fatbird wrote: post #38
ngrilly wrote: post #36

Earlier quoted context omitted.

Did you store the plain text of each PDF in PostgreSQL or just the ts_vector resulting from the plain text?

IIRC, I stored the plain text too because the engine can return contextually marked up plaintext after finding it in the ts_vector.

You're right, PostgreSQL needs the plain text to highlight it with ts_headline. It's similar to Elasticsearch keeping the original document in the _source attribute. Thanks!

Re: PostgreSQL 9.6 Released

#50

Post by ngrilly »

pilif wrote: post #39
fabian2k wrote: post #17

Just from reading the documentation, the full text search features on Postgres already look pretty powerful. And it is encouraging that they are actively being worked on. I'm wondering how this compares to a dedicated search engine like Solr or Elasticsearch. Are there huge differences in performance, features or search quality? At which scale does using Postgres for full text search still make sense?

While it's ok for our purposes, I would wish for a bit better customisability of the text parser and it definitely needs better support for compound words to be perfect. The first issue is with relation to https://www.postgresql.org/docs/9.6/static/textsearch-parser... : The documentation says > At present PostgreSQL provides just one built-in parser, which has been found to be useful for a wide range of applications…

Do you rank full-text search results using something like ts_rank? If yes, do you suffer from slow queries?
Post reply on HN