Skip site navigation (1) Skip section navigation (2)

Re: Using null date fields to indicate active/expired records

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: (view raw, whole thread or download thread mbox)
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.


David Fetter david(at)fetter(dot)org
phone: +1 510 893 6100   mobile: +1 415 235 3778

Remember to vote!

In response to

sfpug by date

Next:From: eleinDate: 2004-08-07 18:37:04
Subject: Linux World experiences
Previous:From: Josh BerkusDate: 2004-08-06 17:27:17
Subject: Re: Using null date fields to indicate active/expired records

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group