Re: efficient data reduction (and deduping)
| От | Alessandro Gagliardi |
|---|---|
| Тема | Re: efficient data reduction (and deduping) |
| Дата | |
| Msg-id | CAAB3BB+c4+Y5E0hzsfo6fi-y1acOZFYjE+EY2cJmYZM4h0TjpQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: efficient data reduction (and deduping) ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
| Ответы |
Re: efficient data reduction (and deduping)
|
| Список | pgsql-performance |
All of our servers run in UTC specifically to avoid this sort of problem. It's kind of annoying actually, because we're a San Francisco company and so whenever I have to do daily analytics, I have to shift everything to Pacific. But in this case it's handy. Thanks for the keen eye though.
On Thu, Mar 1, 2012 at 10:51 AM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote:
In addition to the responses which more directly answer your
question, I feel I should point out that this will not represent a
single moment in time. At the end of Daylight Saving Time, the
value will jump backward and you will run through a range of time
which will overlap existing entries. There is almost never a good
reason to use TIMESTAMP WITHOUT TIME ZONE -- TIMESTAMP WITH TIME
ZONE is required if you want the value to represent a moment in
time.
-Kevin
В списке pgsql-performance по дате отправления: