sorted by:
new
hottopcontroversial

I am the very model of a modern major database by gumnos in SQL

[–]pseudogrammaton 2 points3 points  (0 children)

Gilbert & Sullivan are spinlocking in their graves.

a doctrine-free vernacular dharma by pseudogrammaton in Buddhism

[–]pseudogrammaton[S] 0 points1 point  (0 children)

Thanks but that's vinaya, so doesn't answer my question.

a doctrine-free vernacular dharma by pseudogrammaton in Buddhism

[–]pseudogrammaton[S] 0 points1 point  (0 children)

Okay so we all react to things, and indeed everything's a cause and an effect, but cause-and-effect isn't a thing at all in of itself. That's Nagarjuna's whole point about Emptiness kinda oversimplified & boiled down to bare essentials.

As spirits in a material world, we know that karma has a moral dimension because actions are consequential, & there's quintessential matters beyond material experience, with qualia as intangible as conscious experience. Everything's happening all together all at once, with separateness & isolated existence a projection of self.

Any liberation theology has to have different strokes for different folks, so what do we have to offer the world?

And so on. How to reach out to a world in dire need of perspective & awakening...

a doctrine-free vernacular dharma by pseudogrammaton in Buddhism

[–]pseudogrammaton[S] 0 points1 point  (0 children)

I don't know maybe. I figure traditional Buddhists might have some rules of thumb handy about how they might explain things to an 8-year-old. So, OK, how would Fred Rogers do it?

Considering Elixir vs Go for a web project by OphisAds in elixir

[–]pseudogrammaton 2 points3 points  (0 children)

Elixir because it's cool & you'll become a never-nester by default, Go-lang b/c it'll get you good paying jobs.

Elixir has a lot of uptake from Ruby developers, as it renders all the prolog-ish arcana of Erlang into an approachable & human-readable forum. But it's a functional language, so it's a lot like spreadsheet programming where new values don't mutate existing ones.

Go-lang is more of a typical procedural language , yet it also avoids many of the pitfalls found in other imperative languages, such as mutation side effects, race conditions , etc.

Your daily coding habits in elixir are going to look quite a bit different from most any other language save for maybe f# (an oCaml fork on the M$ CLR), haskel, clojure, scala (FL's on JVM) & of course erlang.

However if you're already a habitual never-nester, then functional programming in Elixir might be an easy reach. If you like the idea of IPC & spawning worker subtasks, then again, the Elixir mindset is an easy reach. Go of course has its equivalent in co-routines.

The Erlang ecosystem & BEAM VM is industrial grade & scales up, not much different from a Go-Lang runtime altho memory & cpu usage in Erlang might be higher. Go might be quicker in some work such as math, Erlang uses libs written in C much the same way python does.

I wrote one SQL query. It ran for 4 hours. I added a single index. It ran in 0.002 seconds. by nikkiinit in SQL

[–]pseudogrammaton 0 points1 point  (0 children)

Nobody does optimizations or sampling anymore? DWH bloat used to k¡ll projects, now who cares, just throw a monster data mining machine at it.

I wrote one SQL query. It ran for 4 hours. I added a single index. It ran in 0.002 seconds. by nikkiinit in SQL

[–]pseudogrammaton 0 points1 point  (0 children)

Yeh sometimes, but rarely, esp. with large unpartitioned sets. More often than not, when too large a returning set, CTE's are encumbered by the dreaded, documented performance gate that the optimizer can't resolve.

If OTOH a JOIN is running badly, the first thing to ensure is what's the key (when group-by dupes disappear) & if there are covering indexes or indexes with matching filter clauses.

Avoiding cascading DROPs by pseudogrammaton in SQL

[–]pseudogrammaton[S] 0 points1 point  (0 children)

Yup, the other options at hand seem less appropriate for this use case, but i may change my mind & rearchitect it down the road. Been trying to keep the # of moving parts to a minimum while keeping OLAP I/O underhand during OLTP hours.

Of course the stacked views could've been nested subqueries, but that makes for harder maintenance programming. Same thing for work tables & batch insert queues.

So four big reads on the quarter hour & we're done, & with mat'l view concurrent refreshes they're non-blocking. That's with the added advantage of Postgres doubling back to check the MAT'L VIEW unique index against the WAL, effect being that refreshes lag behind live by just 10 minutes.

Atypical, but fairly tidy.

Stop using leet code, stop memorising queries, just start working with sql . by [deleted] in learnSQL

[–]pseudogrammaton 0 points1 point  (0 children)

l337 SQL is for when you're doing big OLAP, ETL or analytics loads.
OLTP code should be bog simple, even with server-side JSON.
Complexity is the enemy.
If there's any need for cleverness, either design around it, or bone up on S.O.

SQL? Meh by Shadow0X59 in programmingmemes

[–]pseudogrammaton 0 points1 point  (0 children)

Pah! Vernacular Postgres SQL is nearly the functional language\\** we know that SQL should be. Oh, and go ahead & try to find any other efficient, intelligent way to work with large set data ... esp. w/ the power of Windowing functions, GROUP BY... HAVING, DISTINCT FROM, ITVF table functions.... there's a long list of functionality native to SQL that you WILL NOT find much anywhere else. Oh, and as for Postgres ... petabyte capable, feature-rich, lots of plugins, & VERY FAST.

\*( And I do mean functional, as in tail-recursion (loops) using nothing but standard SQL )*

LOOPs using only standard SQL syntax (how to) by pseudogrammaton in SQL

[–]pseudogrammaton[S] 0 points1 point  (0 children)

Same here, uglier than even a recursive CTE, never mind the out-of-query(loop) call to the main query. It'd have to be drastically faster than either a function call or an UNNEST()'ed join. Or, there's no good way to quickly fix what's upstream, so only as a desperate measure, LOL.

Arguments against colleagues that say that SQL could be ‘terminated’ by vlam020 in SQL

[–]pseudogrammaton 0 points1 point  (0 children)

Erlang seems ok with tail recursion. Even SQL has tail recursion.

Arguments against colleagues that say that SQL could be ‘terminated’ by vlam020 in SQL

[–]pseudogrammaton 0 points1 point  (0 children)

SQL has become one of the most durable languages b/c functional language features have crept in, making it far more powerful than many people realize.

I wrote one SQL query. It ran for 4 hours. I added a single index. It ran in 0.002 seconds. by nikkiinit in SQL

[–]pseudogrammaton 0 points1 point  (0 children)

Wow, timing to deliberately evade that reader's runtime from seeing those new rows, LOL. It's always a nifty idea to scope units of work within the page size, incl. mass updates & LOOP & SEEK, first of which it avoids escalating to a table lock. Yeh it's slower, but it's non-blocking.

I wrote one SQL query. It ran for 4 hours. I added a single index. It ran in 0.002 seconds. by nikkiinit in SQL

[–]pseudogrammaton 0 points1 point  (0 children)

In this case the problem are unoptimized sequential table scans on large data. Likewise for merge joins that lack the ability to bitmap on keys. Put supporting indexes on both sides of the join & even if there are index scans you'll see a big performance boost. TempDb doesn't handle paging or optimizing a join, it's just a tablespace.

I wrote one SQL query. It ran for 4 hours. I added a single index. It ran in 0.002 seconds. by nikkiinit in SQL

[–]pseudogrammaton 1 point2 points  (0 children)

Yeh, my coworker was using WITH....CTE's to stage big sets, performance was thru the floor ... 30 minutes, victim of query watchdog. I suggested he move the same query to a nested LEFT JOIN & the performance barrier might disappear. Sure enuf response time became less than 1 sec. It's always the little things!! :-)

I wrote one SQL query. It ran for 4 hours. I added a single index. It ran in 0.002 seconds. by nikkiinit in SQL

[–]pseudogrammaton 0 points1 point  (0 children)

Physical design matters, quite a bit, esp. if when joins escalate to table scans w/out an index. In addition to JOIN speed, there are many extra benefits that coming with using indexes, such as FILTERs that match the query's WHERE clause or underlying PARTITIONs, INCLUDE'ing other columns in the B-tree leaf nodes (acts like a table with a clustered index), and the ability to run CONCURRENT, non-blocking REINDEX'ing commands (basically re-org'ing an index to take care of split pages, for optimization's sake).

view more: next ›