On 2012-07-25, Steve Crawford wrote:
>
> How are your determining the space used by a table?
>
> Why are you assuming 7 bytes for a 3-character value? (Character values
> up to 126 characters long only have 1-character overhead.)
character values upto 127 octets long only have one octet overhea
Tom Lane wrote:
> > That's a controversial point: doing it that way makes reordering of
> > large tables highly impractical.
>
> In particular, if the implementation works like that, you hardly need
> any system support at all. You can do the equivalent today with a few
> SQL commands: c
On Thu, Jul 26, 2012 at 11:19 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Thu, Jul 26, 2012 at 11:02 AM, Mike Christensen
>> wrote:
>>> I don't really think you'd need to decouple the internal column order
>>> from what the user sees. A REORDER COLUMNS command should re-build
>>> the ta
On Thu, Jul 26, 2012 at 9:12 AM, Merlin Moncure wrote:
> On Thu, Jul 26, 2012 at 11:02 AM, Mike Christensen wrote:
>> I don't really think you'd need to decouple the internal column order
>> from what the user sees. A REORDER COLUMNS command should re-build
>> the table with the columns in the s
Merlin Moncure writes:
> On Thu, Jul 26, 2012 at 11:02 AM, Mike Christensen wrote:
>> I don't really think you'd need to decouple the internal column order
>> from what the user sees. A REORDER COLUMNS command should re-build
>> the table with the columns in the specified order.
> That's a cont
On Thu, Jul 26, 2012 at 11:02 AM, Mike Christensen wrote:
> I don't really think you'd need to decouple the internal column order
> from what the user sees. A REORDER COLUMNS command should re-build
> the table with the columns in the specified order. Internally, it
> should be no different from
On Wed, Jul 25, 2012 at 4:12 PM, Tom Lane wrote:
> Mike Christensen writes:
>> On Wed, Jul 25, 2012 at 1:35 PM, Tom Lane wrote:
>>> Yeah, this has been discussed multiple times. The sticking point is
>>> the extra infrastructure needed to have a physical column numbering
>>> different from the
> > Has there been any discussion of providing the ability to re-order
> > table columns through an ALTER TABLE command? I would love to see
> > this; when I add in a new column, I often want to put it next to
> > something just to be more visually appealing when I'm running ad-hoc
> > queries. I
100% but don't
SC> know how you are configured.)
I'm using 100%, but it shouldn't matter as I was giving sizes without the index
anyway.
SC> Do the tables have OIDs or not?
No
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Tuesday, July 24, 2012 10:
On 07/26/2012 07:12 AM, Tom Lane wrote:
It's more or less the same discussion. To do either one you need to
decouple the internal column order from what the user sees. I do not
think we'd bother with building the infrastructure involved if the
only application were squeezing out alignment paddi
Mike Christensen writes:
> On Wed, Jul 25, 2012 at 1:35 PM, Tom Lane wrote:
>> Yeah, this has been discussed multiple times. The sticking point is
>> the extra infrastructure needed to have a physical column numbering
>> different from the user-visible numbering, and the 100% certainty of
>> int
On Wed, Jul 25, 2012 at 5:20 PM, Mike Christensen wrote:
> On Wed, Jul 25, 2012 at 1:35 PM, Tom Lane wrote:
>> "McGehee, Robert" writes:
>>> One might even imagine a future version of PostgreSQL using an
>>> efficient disk layout that may not match the table layout in order to
>>> avoid wasted s
On Wed, Jul 25, 2012 at 1:35 PM, Tom Lane wrote:
> "McGehee, Robert" writes:
>> One might even imagine a future version of PostgreSQL using an
>> efficient disk layout that may not match the table layout in order to
>> avoid wasted space from padding.
>
> Yeah, this has been discussed multiple ti
"McGehee, Robert" writes:
> One might even imagine a future version of PostgreSQL using an
> efficient disk layout that may not match the table layout in order to
> avoid wasted space from padding.
Yeah, this has been discussed multiple times. The sticking point is
the extra infrastructure neede
configured.)
I'm using 100%, but it shouldn't matter as I was giving sizes without the index
anyway.
SC> Do the tables have OIDs or not?
No
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Tuesday, July 24, 2012 10:00 PM
To: Adrian Klaver
Cc: McGehee, Ro
Adrian Klaver writes:
> On 07/24/2012 03:21 PM, McGehee, Robert wrote:
>> I've created two tables labeled "Big" and "Small" that both store the same
>> 10 million rows of data using 493MB and 487MB of disk space respectively.
>> The difference is that the "Big" table uses data types that take up
On 07/24/2012 03:21 PM, McGehee, Robert wrote:
Hi,
I've created two tables labeled "Big" and "Small" that both store the same 10 million rows of data using 493MB and 487MB of disk
space respectively. The difference is that the "Big" table uses data types that take up more space (integer rather t
On 07/24/2012 03:21 PM, McGehee, Robert wrote:
Hi,
I've created two tables labeled "Big" and "Small" that both store the same 10 million rows of data using 493MB and 487MB of disk
space respectively. The difference is that the "Big" table uses data types that take up more space (integer rather t
Hi,
I've created two tables labeled "Big" and "Small" that both store the same 10
million rows of data using 493MB and 487MB of disk space respectively. The
difference is that the "Big" table uses data types that take up more space
(integer rather than smallint, float rather than real, etc). The
19 matches
Mail list logo
