TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

PostgreSQL Features to Try

378 点作者 rodmena大约 6 年前

24 条评论

theandrewbailey大约 6 年前
There&#x27;s full text search, but that only does exact matches. To make it more versatile, take a look at trigrams, which forgives you if you don&#x27;t spell something exactly right. It breaks everything into three letter segments, and searches with those.<p><a href="https:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;current&#x2F;pgtrgm.html" rel="nofollow">https:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;current&#x2F;pgtrgm.html</a>
评论 #19768729 未加载
评论 #19767691 未加载
评论 #19771130 未加载
ralusek大约 6 年前
I had a case where I needed to build some denormalized redundant models to handle certain queries. I also had a write-heavy, append-only event log portion of my data model. I figured it would scale very differently, and could be partitioned very differently than the rest of the data, so I wanted to try putting it in a separate DB and using a dblink&#x2F;foreign data wrappers. I use DB triggers and dblink to produce the denormalized data from the event stream, and I consume the denormalized data from my application using pg notify. So, even if I do an insert or update with a SQL statement directly to the DB, it will produce the denormalized data without relying on application logic&#x2F;hooks.<p>It&#x27;s definitely air tight, and nice knowing that no version of my data can currently be inconsistent, but there are definitely costs. For one, it&#x27;s just slow. Bear in mind, I&#x27;m on commodity hardware, like t2, but it still seems slow, as some writes take up to 1-2s. It&#x27;s also not great that it&#x27;s basically magic, I can&#x27;t really make alterations to change or improve what it&#x27;s doing. Lastly, it&#x27;s hard to version control. I have the triggers checked in with my application code, but it would be easy to not even be aware of their existence. On application startup,I override existing triggers with the ones from the code, just to make sure they&#x27;re in sync, and I explicitly log out this process, but I could still see this whole process happening without it being at all clear to another developer.<p>Would I use these features again? Probably not.
评论 #19767250 未加载
评论 #19768038 未加载
paulddraper大约 6 年前
Missing from the list:<p>---<p>1. json functions: json_build_object, json_agg, etc.<p>Ever want to product a hierarchical result set?<p><pre><code> { &quot;groups&quot;: [ { &quot;name&quot;: &quot;Beatles&quot;, &quot;users&quot;: [ { &quot;name&quot;: &quot;John&quot; }, { &quot;name&quot;: &quot;Paul&quot; } ] }, { &quot;name&quot;: &quot;Stooges&quot;, &quot;users&quot;: [ { &quot;name&quot;: &quot;Moe&quot; } ] } ] } </code></pre> Then<p><pre><code> SELECT json_build_object( &#x27;groups&#x27;, json_agg( json_build_object( &#x27;name&#x27;, g.name &#x27;users&#x27;, coleasce(u.users, &#x27;[]&#x27;::json) ) ) value FROM group g LATERAL LEFT JOIN ( SELECT json_agg( json_build_object(&#x27;name&#x27;, u.name) ) users FROM &quot;user&quot; u WHERE g.id = u.group_id ) u ON true </code></pre> Produce your entire JSON result in SQL with full power of aggregations, joins, etc., extensible to any nesting structure.<p>At the extreme, you could use the PostgREST extension make an entire REST JSON API with just PostgreSQL.<p>---<p>2. With PostgreSQL&#x27;s record-level security, end users can get their own connections to the database.<p>You can even have an instant GraphQL server via Postgraphile. [1]<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;PostgREST&#x2F;postgrest" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;PostgREST&#x2F;postgrest</a><p>[2] <a href="https:&#x2F;&#x2F;www.graphile.org&#x2F;postgraphile&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.graphile.org&#x2F;postgraphile&#x2F;</a>
评论 #19768560 未加载
everdev大约 6 年前
A nice list but I&#x27;d also add row-level security (RLS): <a href="https:&#x2F;&#x2F;info.crunchydata.com&#x2F;blog&#x2F;a-postgresql-row-level-security-primer-creating-large-policies" rel="nofollow">https:&#x2F;&#x2F;info.crunchydata.com&#x2F;blog&#x2F;a-postgresql-row-level-sec...</a><p>It&#x27;s amazing how much effort we put into restricting access on the server, but ignore user roles on the data layer.
评论 #19767179 未加载
评论 #19771062 未加载
评论 #19769970 未加载
nightfly大约 6 年前
I&#x27;d add lateral joins to the list <a href="https:&#x2F;&#x2F;medium.com&#x2F;kkempin&#x2F;postgresqls-lateral-join-bfd6bd0199df" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;kkempin&#x2F;postgresqls-lateral-join-bfd6bd01...</a>
评论 #19779424 未加载
评论 #19768938 未加载
评论 #19767981 未加载
asah大约 6 年前
some of my favorites:<p>- transactional DDL: <a href="https:&#x2F;&#x2F;www.google.com&#x2F;search?q=transactional+ddl+postgresql" rel="nofollow">https:&#x2F;&#x2F;www.google.com&#x2F;search?q=transactional+ddl+postgresql</a><p>- expression indexes: <a href="https:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;current&#x2F;indexes-expressional.html" rel="nofollow">https:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;current&#x2F;indexes-expressional...</a><p>- partial indexes: <a href="https:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;current&#x2F;indexes-partial.html" rel="nofollow">https:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;current&#x2F;indexes-partial.html</a><p>- Javascript UDFs (plv8): <a href="https:&#x2F;&#x2F;plv8.github.io" rel="nofollow">https:&#x2F;&#x2F;plv8.github.io</a><p>- hyperloglog: <a href="https:&#x2F;&#x2F;github.com&#x2F;citusdata&#x2F;postgresql-hll&#x2F;releases&#x2F;tag&#x2F;v2.10.2" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;citusdata&#x2F;postgresql-hll&#x2F;releases&#x2F;tag&#x2F;v2....</a>
评论 #19769294 未加载
rodmena大约 6 年前
To me, one of the neatest features was the ability to send notifications from triggers:<p><pre><code> PERFORM pg_notify(&quot;send_sms&quot;, &lt;RECORD&gt;::TEXT); </code></pre> Amazing.
评论 #19768585 未加载
评论 #19768263 未加载
mistrial9大约 6 年前
re Inheritance -- used very well to solve a &quot;Pretty Big Data&quot; problem, making 60 child tables with two fields to differentiate.. some craft is required when building indexes, and in loading the data. Overall this inherited tables solution works very well and had many small positive side effects over time. As always, PG is rock-solid, everytime.
mhd大约 6 年前
Did anyone ever do something really interesting with table inheritance? This is one feature that looks like I might have use cases for all the time, but they never quite fit or offer a good benefit.<p>Foreign data wrappers on the other hand are used by me all the time, as you can have a &quot;common&quot; stuff database and just inject that into all kinds of related ones (like per-tenant setups etc.). I&#x27;ve ran in some issues with joins and performance, but if need be you can just materialize them locally and work from that.
评论 #19768093 未加载
评论 #19776832 未加载
评论 #19767685 未加载
评论 #19767553 未加载
oftenwrong大约 6 年前
How about SKIP LOCKED, which is useful for building advanced queuing setups.
评论 #19767894 未加载
status_quo69大约 6 年前
The <i>one</i> thing I wish that NOTIFY had as a feature would be the ability to do NOTIFY [N], or at least NOTIFY 1. I was writing a very very basic job pool previously and had to try to overcome the thundering herd problem but at the end of it couldn&#x27;t. I know it&#x27;s a niche case and maybe there is a clever way of dealing with it, but the only way that I could find to avoid re-doing work and&#x2F;or trying to select jobs that weren&#x27;t taken was to allow each listener to be notified and lock the row, where each query for a job would be roughly SELECT * FROM jobs WHERE .... FOR UPDATE SKIP LOCKED and then bail out if I couldn&#x27;t find any jobs. I could have been using NOWAIT instead, it&#x27;s been a few years. We weren&#x27;t looking at a huge number of async jobs to occur but needed reliability and auditing. Ultimately I believe that we scrapped this whole idea so it&#x27;s all moot but it definitely would have made prototyping a bit easier
评论 #19769582 未加载
gfiorav大约 6 年前
Beware of using FDW with extensions in Postgres (like PostGIS), since they might be written under the assumption that data is available locally and not over the network (I.e. full table pulls)
lettergram大约 6 年前
I wrote a little post on doing fast text search in postgres:<p><a href="https:&#x2F;&#x2F;austingwalters.com&#x2F;fast-full-text-search-in-postgresql&#x2F;" rel="nofollow">https:&#x2F;&#x2F;austingwalters.com&#x2F;fast-full-text-search-in-postgres...</a><p>I use it regularly and it may help people. Makes use of triggers and some of the other items mentioned.
mythrwy大约 6 年前
What I&#x27;d like is a postgres specific migration scheme that let me take advantage of a lot of cool (and unique) features postgres has without fighting with general purpose ORMs or having to manually edit migration files.
评论 #19768459 未加载
评论 #19792980 未加载
评论 #19768878 未加载
评论 #19769291 未加载
jarym大约 6 年前
Very neat list. If I had the know-how I would do 2 things to Postgres to make some of these items more useful:<p>- Foreign key support for inherited tables (i.e. a foreign key referencing a table with inheritance, the other way round works just fine). Table inheritance is super useful but lack of full foreign key support means we have to give up on some integrity (or replace them with hand-written constraints).<p>- Bloom indexes on arrays and bigint (int8) types - would make it feasible to (almost) &#x27;index all things&#x27; when working mostly with numeric data.
评论 #19771111 未加载
ken大约 6 年前
Table inheritance sounds neat, but the limitations are so severe I&#x27;ve never found a case where it&#x27;s better than just adding a JSON column.<p>The manual says &quot;These deficiencies [with table inheritance] will probably be fixed in some future release&quot; -- and has since at least 2002, so I think it&#x27;s safe to assume the situation will never improve.
评论 #19771838 未加载
VectorLock大约 6 年前
The table inheritance one is something I wasn&#x27;t aware of. I can think of so many great uses for it that it makes me kind of weary. There has to be some downside, its too good.
评论 #19767896 未加载
评论 #19767657 未加载
xtracto大约 6 年前
Haha , subtle marketing bite. Did not see it coming.<p>One thing is not like the others.<p>Interesting the pub&#x2F;sub. Anyone tried it? It s it ok for production loads?
ed_blackburn大约 6 年前
NOTIFY and LISTEN appeals a lot but my understanding is LISTEN needs to be on the same connection, which isn’t realistic with connection pooling etc? Anyone got any experience with this feature?
评论 #19767426 未加载
评论 #19767491 未加载
评论 #19767268 未加载
评论 #19767471 未加载
评论 #19767620 未加载
victor106大约 6 年前
Previous discussion<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17356960" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17356960</a>
jpgvm大约 6 年前
Should also add advisory locks to this list. They are a little known but incredibly useful feature.
评论 #19774301 未加载
swasheck大约 6 年前
I’ve seen 3 or 4 of these posts over the last few months and they all seem to have half in common with each other. At this point do we need more posts calling attention to FDW and Table Inheritance as things nobody’s using&#x2F;heard of? They’re certainly nifty, but I’d like more deep dives on PG internals and tuning to gain a bit more publicity on HN.
faitswulff大约 6 年前
Now I&#x27;m curious: how far can you get in writing a simple REST API using just PostgreSQL?
评论 #19768906 未加载
rezoner大约 6 年前
How about UPDATE LIMIT 1 instead of fancy edge case features?
评论 #19767627 未加载
评论 #19767629 未加载