« first day (1366 days earlier)   

1:15 AM
@PaulWhite are you still around?
 
Yes.
 
sweet. quick question. i've been attempting to test this but i want to see if there's already an answer out there. is the impact of data-moving page splits more severe on a defragmented index?
 
1:33 AM
@PaulWhite not sure if you have any thoughts on the above.
 
@swasheck What sort of page split doesn't move data? And by "defragmented" do you mean an index with no free space? i.e. 100% FILLFACTOR?
= unclear what you're asking :)
 
@PaulWhite hm. maybe i'm misunderstanding things. mid-page splits. and i'm meaning a freshly-rebuilt index with fillfactor 100%
 
Well a "bad" page split always moves ~half of the rows to a new page.
 
right. so i guess that's what i'm talking about
 
So I'm going to go with a tentative "no".
 
1:39 AM
tentative "no" because i'm not capable of clearly articulating what i'm asking? or tentative "no" because theoretically you dont think it should but can't verify? :) because i'm feeling the former.
 
Correct.
 
i've just been doing some testing based on some developer feedback we've received
 
But the more I think about it, the more I'm sure the cost of a "bad" page split doesn't depend on the existing fragmentation state of the index.
Except that an index with lots of free space is less prone to split in the first place of course.
 
we have an overnight job that inserts data ... combo of acceptable and bad page splits are part of what's occurring. the job is significantly slower the day after we run our index defrag/maintenance scripts. another teammate is evaluating the quantity and characteristics of the data
 
Have you guys tried pumpkin spice joins?
 
1:42 AM
@PaulWhite but i decided to see if fragmentation affected the performance of splits.
and i'm not sure how that'd be tested
and i decided to ask to see if anyone knew off the top of their heads anyway
@PaulWhite right
 
@swasheck Are you sure you're not just seeing more bad splits on the freshly-maintained index? Why maintain at 100% if you expect inserts?
 
@PaulWhite a) no. i'm not sure about that yet. b) inherited tech. debt. this is the first step in changing from the default fillfactor of 0
 
Ok well there's something to measure then.
 
@PaulWhite i guess that's my thought --- would more = longer (theoretically)?
 
In general, yes.
Doing more of anything often takes more time, right?
 
1:47 AM
ok
so that was my line of thinking but i wanted to make sure that i was granular enough (evaluating both acceptable and "bad" splits) to ensure that i wasnt misrepresenting splits in general
@PaulWhite thanks for your help. sorry i have such difficulty formulating a decent question/thought
 
I would ignore the good page splits. Adding a fresh page to the end of an index is not something you can improve much.
No worries. You caught me in the middle of writing an article, so I was a bit preoccupied.
 
@PaulWhite fillfactor wouldnt even improve that, right? also - it's not just now ... i do tend to turn into an SO user when i ask questions that are in uncharted territory for me
 
Right. A new page added to the end of an index is a new page, full stop. No fillfactor effect.
 
figured
 
 
5 hours later…
6:30 AM
@Kermit Are those web scale?
 
7:06 AM
silly joke
1
A: How to save an interval of years in postgresql

Neil McGuiganYou could use an two smallint columns: create schema ponzi; /* a ponzi schema! Totally unnecessary */ create table foo ( from_year smallint not null, to_year smallint not null, check (from_year = to_year - 1 and from_year >= extract(year from current_date)), unique (from_year, to_year)...

 
7:28 AM
spam:
-2
A: copying 1.2 GB mdb from pc to network

jefferycarson816large MDB files have threat go get corrupt so it is advisable to use small files on server. But in the case of mdb file corruption you can use Access Fix Toolbox to get back your corrupt data. http://www.access.fixtoolbox.com/ Kindly refer to the page for instruction and download of the solution:...

 
 
4 hours later…
11:37 AM
hi
 
12:03 PM
@James of course.
 

« first day (1366 days earlier)