David Fetter's blog - Comments

Marc Tardif: Adding Only New Rows (INSERT IGNORE, Done Right)

nospam@example.com (Marc Tardif) — Mon, 21 Jun 2010 23:16:52 +0300

@depesz

The first fail scenario can probably be prevented by adding GROUP BY v.id, v.t in the WHERE clause.

Pavel Stehule: Part(ition)ing Glances

nospam@example.com (Pavel Stehule) — Wed, 05 May 2010 20:30:21 +0300

I understand now - the problem is in wiki syntax some means bold. nice trick

Pavel Stehule: Part(ition)ing Glances

nospam@example.com (Pavel Stehule) — Wed, 05 May 2010 19:44:00 +0300

Hi

I see RETURN NEW first time. What is it?

David Fetter: Part(ition)ing Is Such Sweet Sorrow

nospam@example.com (David Fetter) — Wed, 05 May 2010 02:46:27 +0300

Gerard,

Thanks for the heads-up. I think I've fixed this here: http://people.planetpostgresql.org/dfetter/index.php?/archives/59-Partitioning-Glances.html

Emmanuel: psql, Paste, Perl: Pefficiency!

nospam@example.com (Emmanuel) — Thu, 29 Apr 2010 18:21:16 +0300

Very nice and efficient !

A small typo: on my freebsd station i had to change encodings' names in iconv:
ISO88591 -> ISO-8859-1
UTF8 -> UTF-8.

In the second regexp, i escaped the pipes otherwise it returned only the first field (understood as OR in catch pattern). There were certainly removed during the post submission.

$l =~ s/^([^|]+\|[^|]+\|[^|]+\|[^|]+).*/$1/;

I luv' perl

Gerhard Heift: Part(ition)ing Is Such Sweet Sorrow

nospam@example.com (Gerhard Heift) — Sun, 18 Apr 2010 10:29:25 +0300

The problem with this solution is: you cannot use INSERT RETURNING or UPDATE RETURNING.

Do you know a workaround?

Robert Hodges: Partly Cloudy, with a Very High Chance of FAIL

nospam@example.com (Robert Hodges) — Fri, 09 Apr 2010 09:10:52 +0300

Thanks Dave! Nice topic BTW.

David Fetter: Partly Cloudy, with a Very High Chance of FAIL

nospam@example.com (David Fetter) — Fri, 09 Apr 2010 02:26:27 +0300

Sorry about that. He's off.

Robert Hodges: Partly Cloudy, with a Very High Chance of FAIL

nospam@example.com (Robert Hodges) — Thu, 08 Apr 2010 23:06:23 +0300

Congratulations, you win today's web politeness award. Thanks for playing.

Faptor Jerkosovic: Partly Cloudy, with a Very High Chance of FAIL

nospam@example.com (Faptor Jerkosovic) — Thu, 08 Apr 2010 22:13:25 +0300

COMMENT_DELETED

Robert Hodges: Partly Cloudy, with a Very High Chance of FAIL

nospam@example.com (Robert Hodges) — Thu, 08 Apr 2010 21:00:24 +0300

p.s., Most ISPs effectively use clouds for their base-level hosting offerings and have been doing so for years. Cloud in this case is a programmable ops environment based on hardware virtualization. If you sign up for the $10/month email and blog service at www.joes.blogomatic.net chances are good the apps are running in a cloud. However, while most large ISPs I know run the web server and mail service on a VM, they connect back to a shared DBMS server, typically MySQL. This kind of mixed model is another reason why it's very hard to generalize.

Robert Hodges: Partly Cloudy, with a Very High Chance of FAIL

nospam@example.com (Robert Hodges) — Thu, 08 Apr 2010 20:49:46 +0300

Databases and the applications that use them have become so diverse it's really hard to make generalizations. I know one marketing research firm that already hosts most of their applications including databases in the cloud--cost scaling and flexibility are more important than security and performance. We host our own company website and IT systems at Amazon. It cut our hosting expenses by about 90%. The cloud is also very convenient for testing as Jim says.

That said, for the most part companies running business-critical apps on conventional RDBMS are not running to deploy in the cloud. We backed off putting in explicit cloud support for our own database clustering products because there is no demand. For these sorts of users the cloud is just a bunch of hype.

Faptor Jerkosovic: Partly Cloudy, with a Very High Chance of FAIL

nospam@example.com (Faptor Jerkosovic) — Wed, 07 Apr 2010 19:04:49 +0300

The comments are better than the article. He says ``I disagree'' but gradually seems to forget what he disagrees with as he sinks into a warm gooey tub of autistic techno-fappage.

Jim Mlodgenski: Partly Cloudy, with a Very High Chance of FAIL

nospam@example.com (Jim Mlodgenski) — Wed, 07 Apr 2010 15:47:59 +0300

I disagree. While there are many things about public clouds that are less than ideal for running high throughput transactional applications, most business applications don't need 8+ spindles for its IO or 99.999% uptime. There is no technical reason that most websites, email systems, and reporting applications could not run in a public cloud. I see the issue more as a business one. It is just cheaper to go to your local hosting company and ask for a managed server than it is to pay Amazon $0.50/hour + storage space + data transfer fees +++.

That being said, I don't think most business are ready to move their production data to a public cloud and they may never be ready. I see the public cloud as a perfect development and testing platform. I've actually used it a bit to play with SR/HS in 9.0. I was able to spin up a few 8CPU instances (which we don't have those types of spare boxes laying around the data center) and start beating on the instances in a few minutes.

Michael Shuler: Git + bash = win

nospam@example.com (Michael Shuler) — Fri, 05 Mar 2010 18:37:07 +0200

Here's my adaptation to not hijack the existing $PS1 and put the branch name in red at beginning of prompt:

if [ -f /etc/bash_completion ]; then
. /etc/bash_completion
PSGIT='\[\033[01;31m\]$(__git_ps1 "(%s)")\[\033[00m\]'
PS1="${PSGIT}${PS1}"
fi