Well there's an interesting setting for a database: postgresql.org/docs/9.4/runtime-config-wal.html#GUC-FSYNC

that website is not reading friendly

needs a night mode

what does it say?

I guess maybe it's similar to delayed durability in SQL Server.

> If this parameter is on, the PostgreSQL server will try to make sure that updates are physically written to disk, by issuing fsync() system calls or various equivalent methods (see wal_sync_method). This ensures that the database cluster can recover to a consistent state after an operating system or hardware crash.

sounds depressing

I think delayed durability is like synchronous_commit

> While turning off fsync is often a performance benefit, this can result in unrecoverable data corruption in the event of a power failure or system crash. Thus it is only advisable to turn off fsync if you can easily recreate your entire database from external data.

@JoeObbish Ah, so this is even more unsafe, I guess?

yes

I saw a blog post today that was advocating a case for this setting when doing automated unit testing. Which makes sense.

joe

@JoeObbish

@ErikDarling

i found a new 2d love that isn't anime

you don't even watch anime

stop frontin

@jadarnel27 (makes a sense) just a bit. Only to shorten the tests duration.

@ypercubeᵀᴹ Right, that was the goal in the post!

pythonspeed.com/articles/faster-db-tests

just create the database in ram

problem solved

@ErikDarling I don't know what this is

and i'm the one frontin.

yes

I've never seen subtitles like that

did you buy a dvd off the streets?

first off

i don't go outside

it's too 3d

second

wife and kids are in boston visiting grandparents

i will watch any anime that i can for the next three days

@jadarnel27 I would say using a RAMdisk would be even better. They mention it, too.

Oh Joe already said the same!

@ErikDarling and you haven't seen ALITA yet?

also winter is almost over

you know what you have to do

@JoeObbish no, have you?

@JoeObbish winter is forever when you're independent

@ErikDarling I'm undecided

but those eyes @_@

@jadarnel27 are you working with Postgres or it was just academic reading?

it's kind of like reading a comic book

@ypercubeᵀᴹ Right, but that was less interesting =P

"A pileup of clichés in service to technological whiz-bangery"

@ypercubeᵀᴹ Just academic, it came up in my Google news feed thingy.

> academic

> google news feed thingy

-__-

> 4. Having little practical use or value, as by being overly detailed, unengaging, or theoretical: having no practical importance.

nothing from charles barkley

whatever

Funny how the item is number 4 in the web page but renders as 5 here.

SO bug

> accusing SO of having bugs

@ErikDarling I'm very intellectual like that.

@ErikDarling Okay, that story was amazing.

😊

@ErikDarling Can bitmaps even occur on an outer join?

@Forrest yes

Oooohh

depends what you mean I guess

you can get a bitmap depending on which side is chosen for the build

I am trying to process questions and finding my mental model of a bitmap insufficient.

A bitmap only affects columns that are present in the join condition, yes?

otherwise how could it be applied to the probe table?

a bitmap can be created on any column from the hash build side in theory, but it would serve no purpose unless it's on a join column

i'm failing miserably at getting a plan with a bitmap on a left join

would you say it's rare?

when i do it get, the optimizer commutes to an inner join

I see it on the daily

maybe add some operations that increase the cost of returning a row from the probe side?

I'll cook it up

CREATE TABLE #nou (ID INT);

INSERT INTO #nou WITH (TABLOCK)
SELECT ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM master..spt_values;

CREATE TABLE #big_guy (ID INT);

INSERT INTO #big_guy WITH (TABLOCK)
SELECT ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;

GO

SELECT *
FROM #nou t1
LEFT OUTER JOIN #big_guy t2 ON t1.ID = t2.ID;

this guy with the heaps

> wanting a hash join

> creating indexes

> mfw

sounds like someone has never seen a big table

for u

Certainly not very realistic.

it's as realistic as Erik's UDF definitions

i feel seen

@ErikDarling I have a dumb question for you

it's about L O G S H I P P I N G

yes please!

let's say I have a BIG workload

that changes lots of data

it finishes after 30 minutes

I take my log backup

and ship it

can anything be said about how long it will take to apply that backup to the secondary database? assuming identical hardware?

should I be expecting 30 minutes, <30 minutes, >30 minutes?

i think your biggest foe would be if the log file on the receiving end has to grow

what if I grow it ahead of time?

exactly

you might be able to use backup time as some gauge of restore time

keep in mind that if the log shipping database is in standby it'll take longer

v. confusing

how so?

so it has nothing to do with the 30 minutes that the workload took?

i'd be very surprised if there were any timing similarity beyond coincidence

is there a predictor?

size of the log file?

yes but it will depend quite a bit on disk hardware (and any need to grow)

optimizing a server for fast restore times means that shipping will be faster too? since it's the same thing?

Yeah I mean it's essentially just writing a file

Twice-ish

well the changes have to be applied to the data files

that's why i said twice-ish

I don't like it

ADR

that wouldn't apply to log shipping, right?

Why not

"With ADR, the transaction log is only processed from the last successful checkpoint (or oldest dirty page Log Sequence Number(LSN). As a result, recovery time is not impacted by long running transactions."

so it could help with log shipping if you take your log backups during long running transactions?

trying to think through this hurts my head

I'm going to go outside instead

Sounds dangerous.

And cold.

@jadarnel27 it was only 23

Oh.

Did you build a snowman?