On Thu, Sep 23, 2010 at 02:33:06PM -0400, Robert Haas wrote:
I'm worried about how we're going to manage that. First, as
pg_upgrade becomes more mature, the penalty for breaking on-disk
compatibility gets a LOT bigger. I'd like to think that the next
time we break on-disk compatibility means
On 9/22/10 6:00 PM, Tom Lane wrote:
I think you missed the point of my response, which is that there are
easily 106 more-pressing things to work on than the size of timetz.
Do you know of any actual use cases for it?
It would be a good project to add to the list of easy TODOs to get
started
Josh Berkus wrote:
On 9/22/10 6:00 PM, Tom Lane wrote:
I think you missed the point of my response, which is that there are
easily 106 more-pressing things to work on than the size of timetz.
Do you know of any actual use cases for it?
It would be a good project to add to the list of
On Thu, Sep 23, 2010 at 1:29 PM, Bruce Momjian br...@momjian.us wrote:
Josh Berkus wrote:
On 9/22/10 6:00 PM, Tom Lane wrote:
I think you missed the point of my response, which is that there are
easily 106 more-pressing things to work on than the size of timetz.
Do you know of any actual
Robert Haas robertmh...@gmail.com writes:
On Thu, Sep 23, 2010 at 1:29 PM, Bruce Momjian br...@momjian.us wrote:
Josh Berkus wrote:
It would be a good project to add to the list of easy TODOs to get
started with.
Except for the pg_upgrade issue.
Which is a big except.
Yeah. That
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Sep 23, 2010 at 1:29 PM, Bruce Momjian br...@momjian.us wrote:
Josh Berkus wrote:
It would be a good project to add to the list of easy TODOs to get
started with.
Except for the pg_upgrade issue.
Which is a big
On Thu, Sep 23, 2010 at 1:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Sep 23, 2010 at 1:29 PM, Bruce Momjian br...@momjian.us wrote:
Josh Berkus wrote:
It would be a good project to add to the list of easy TODOs to get
started with.
Except for
Excerpts from Robert Haas's message of jue sep 23 14:33:06 -0400 2010:
I'm worried about how we're going to manage that. First, as
pg_upgrade becomes more mature, the penalty for breaking on-disk
compatibility gets a LOT bigger. I'd like to think that the next
time we break on-disk
Robert Haas wrote:
On Thu, Sep 23, 2010 at 1:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Sep 23, 2010 at 1:29 PM, Bruce Momjian br...@momjian.us wrote:
Josh Berkus wrote:
It would be a good project to add to the list of easy TODOs to get
On Thu, 2010-09-23 at 15:20 -0400, Bruce Momjian wrote:
decide to break it when we run into a feature that we really want that
can't be had any other way? If we want to make breaking on-disk
compatibility something that only happens every 5 years or so, we had
better give people - I
Joshua D. Drake wrote:
On Thu, 2010-09-23 at 15:20 -0400, Bruce Momjian wrote:
decide to break it when we run into a feature that we really want that
can't be had any other way? If we want to make breaking on-disk
compatibility something that only happens every 5 years or so, we had
All,
I was just checking on our year-2027 compliance, and happened to notice
that time with time zone takes up 12 bytes. This seems peculiar, given
that timestamp with time zone is only 8 bytes, and at my count we only
need 5 for the time with microsecond precision. What's up with that?
Also,
On 22 September 2010 22:01, Josh Berkus j...@agliodbs.com wrote:
All,
I was just checking on our year-2027 compliance, and happened to notice
that time with time zone takes up 12 bytes. This seems peculiar, given
that timestamp with time zone is only 8 bytes, and at my count we only
need 5
Josh Berkus j...@agliodbs.com writes:
I was just checking on our year-2027 compliance, and happened to notice
that time with time zone takes up 12 bytes. This seems peculiar, given
that timestamp with time zone is only 8 bytes, and at my count we only
need 5 for the time with microsecond
On Wed, Sep 22, 2010 at 10:54:53PM +0100, Thom Brown wrote:
On 22 September 2010 22:01, Josh Berkus j...@agliodbs.com wrote:
All,
I was just checking on our year-2027 compliance, and happened to notice
that time with time zone takes up 12 bytes. ?This seems peculiar, given
that
Also, what is the real range of our 8-byte *integer* timestamp?
See the fine manual. I believe the limits have more to do with
calendar arithmetic than with the nominal range of 2^64 microseconds.
I'm asking based on that. The docs only give the limits for a *float*
timestamp. I'd like
On 22 September 2010 22:58, Kenneth Marshall k...@rice.edu wrote:
On Wed, Sep 22, 2010 at 10:54:53PM +0100, Thom Brown wrote:
On 22 September 2010 22:01, Josh Berkus j...@agliodbs.com wrote:
All,
I was just checking on our year-2027 compliance, and happened to notice
that time with time
Josh Berkus j...@agliodbs.com writes:
Also, what is the real range of our 8-byte *integer* timestamp?
See the fine manual. I believe the limits have more to do with
calendar arithmetic than with the nominal range of 2^64 microseconds.
I'm asking based on that. The docs only give the
It's the same, because the limits are calendar based (particularly,
the Julian-date functions) and not dependent on the representation.
Hmmm? Just storing dates for the range described (until the year
294,000) takes 8bytes by my calculations. And that's without the 3
bytes for the time zone.
Josh Berkus j...@agliodbs.com writes:
It's the same, because the limits are calendar based (particularly,
the Julian-date functions) and not dependent on the representation.
Hmmm? Just storing dates for the range described (until the year
294,000) takes 8bytes by my calculations. And that's
timestamptz stores GMT; it doesn't store timezone separately.
(If it did, we'd need more than 8 bytes...)
Oh, yeah. Duh.
Because we haven't lifted a finger to optimize it.
Well, that's a direct answer. Ok, will put it in the list of TODO next
time we change the on-disk format.
--
On Wed, Sep 22, 2010 at 7:20 PM, Josh Berkus j...@agliodbs.com wrote:
timestamptz stores GMT; it doesn't store timezone separately.
(If it did, we'd need more than 8 bytes...)
Oh, yeah. Duh.
Because we haven't lifted a finger to optimize it.
Well, that's a direct answer. Ok, will put it
Robert Haas robertmh...@gmail.com writes:
Technically, there's no reason why we can't do this for 9.1. What we
can do is change the name of the time with timezone type to
something like oldtimetz, keeping the current OID. And then we can
add a new type called time with timezone. [ with
On Wed, Sep 22, 2010 at 9:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Technically, there's no reason why we can't do this for 9.1. What we
can do is change the name of the time with timezone type to
something like oldtimetz, keeping the current OID.
24 matches
Mail list logo
