

UPSERTisms in Postgres - JoelJacobson
http://johtopg.blogspot.se/2014/04/upsertisms-in-postgres.html

======
chrisbolt
The graphs remind me of
[https://news.ycombinator.com/item?id=7588929](https://news.ycombinator.com/item?id=7588929)
(specifically the truncated Y-axis)

~~~
inportb
I don't find these plots misleading. A line plot emphasizes slope and changes
in slope, rather than the absolute heights of the data points as a bar or area
plot would; so it's more important to have consistent vertical and horizontal
intervals.

~~~
joesb
Supposed solution A changes from 10000 to 10001 and solution B changes from
10000 to 10000.5, emphasizing only the slopes doesn't tell you that this
changes may be insignificant.

The given link above (How to lie with data visualization) gives axis
truncation as a very first examples.

~~~
inportb
Indeed, and I disagree with the article regarding axis truncation of line
plots, in this context.

I'd also be careful with terms such as "insignificant" when we're talking
about data. Suppose that tiny difference _were_ significant. Depicting it as a
bar would completely mask the difference, and truncating the axis would give
the false impression of the bar's height representing the total magnitude.
There'd be a similar effect with a line plot, but the line focuses on
continuity and de-emphasizes height: it's not as big of a problem.

There are myriad ways to tell stories using data, and there are myriad ways to
tell misleading stories using data. Each type of plot has distinctive
properties that make it more or less appropriate to be used/manipulated in
certain ways, so I'd hesitate to apply a static set of rules indiscriminately.

------
muxxa
The author dismisses the RULE based approach. I'd love to see it compared, as
it was the only thing that I could get to complete for a multi-GB table merge
(I can't recall what other approaches I tried).
[http://stackoverflow.com/a/6176044/6691](http://stackoverflow.com/a/6176044/6691)

It would be a boon if upsert was supported as a declarative primitive in psql
so that the query planner can do it's magic. Pity it didn't make it in 9.4.

~~~
johto
Author here. I dismissed RULEs and TRIGGERs since they don't work correctly
under concurrency (and most RULE-based approaches are broken even without
concurrency). I felt it wasn't a fair comparison.

However, I guess it would be nice to know how much of a gain would be possible
if one was willing to forfeit correct behaviour under concurrency. But that
would probably require more work than I'm willing to put in, since the answer
doesn't interest me that much personally at this moment.

------
ExpiredLink
BTW, why is it called UPSERT (ugly) and not MERGE (less ugly) as in DB2?

~~~
ldng
AFAIK, it is because UPSERT are only a subpart of MERGE. The devs plan to add
real MERGE in a later release (9.5 or 9.6, I don't remember). Someone more
knowledgeable should shim in for the details.

