From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | SF Postgres <sfpug(at)postgresql(dot)org> |
Subject: | Re: Using null date fields to indicate active/expired records |
Date: | 2004-08-06 19:08:53 |
Message-ID: | 20040806190853.GM27306@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | sfpug |
On Fri, Aug 06, 2004 at 10:27:17AM -0700, Josh Berkus wrote:
> Brian,
>
> > Approximately 14 billion. Ok, I'm kidding, but can anyone answer
> > my question? Although this might be micro-optimization, does it
> > hurt to know more about date performance?
>
> No, there's nothing wrong with knowing. What David and I are
> asserting is that your decision should be determined by having a
> correct data model, and not by counting bits, unless you're in a
> really extreme situation where you have already tested and know you
> have a problem.
>
> Josh's Database Rules #3: the performance loss for slow queries is
> generally exceeded by the downtime caused by a bad data model by a
> factor of 100 or more.
A corollary, Dave's Database Rule #187, is that Josh's Database Rule
#3 wildly underestimates this factor.
> > There are two parts to my question; one, which is faster, and two,
> > does anyone have any advice about using either a single boolean
> > flag or using a 1-n type date?
>
> Which is faster depends on your query structure and the distribution
> of your data; that's the other reason not to make decisions on this
> basis now. If you want a serious answer on this, please post your
> current table structure and an explanation of what kind of data is
> kept in the various fields and how you query it.
Yep.
Cheers,
D
--
David Fetter david(at)fetter(dot)org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!
From | Date | Subject | |
---|---|---|---|
Next Message | elein | 2004-08-07 18:37:04 | Linux World experiences |
Previous Message | Josh Berkus | 2004-08-06 17:27:17 | Re: Using null date fields to indicate active/expired records |