From: | Michael Robinson <robinson(at)netrinsics(dot)com> |
---|---|
To: | lockhart(at)alumni(dot)caltech(dot)edu, tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pgsql-hackers(at)hub(dot)org, robinson(at)netrinsics(dot)com |
Subject: | Re: [HACKERS] regression bigtest needs very long time |
Date: | 1999-07-01 02:52:52 |
Message-ID: | 199907010252.KAA05477@netrinsics.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
>> > The question, though, becomes what percentage of operations on a
>> > NUMERIC field are arithmetic, and what percentage are storage/retrieval.
>> Good point.
>We assume that most data stays inside the database on every query.
>That is, one should optimize for comparison/calculation speed, not
>formatting speed. If you are comparing a bunch of rows to return one,
>you will be much happier if the comparison happens quickly, as opposed
>to doing that slowly but formatting the single output value quickly.
>An RDBMS can't really try to optimize for the opposite case, since
>that isn't how it is usually used...
The optimizations under discussion will not significantly affect comparison
speed one way or the other, so comparison speed is a moot issue.
The question, really, is how often do you do this:
select bignum from table where key = condition
versus this:
select bignum1/bignum2 from table where key = condition
or this:
select * from table where bignum1/bignum2 = condition
-Michael Robinson
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 1999-07-01 03:26:04 | Re: [HACKERS] regression bigtest needs very long time |
Previous Message | Hiroshi Inoue | 1999-07-01 01:33:49 | RE: [HACKERS] 6.5.1 status |