On Fri, 30 Nov 2018 at 02:01, Peter Eisentraut
wrote:
> committed
Thanks
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 29/11/2018 00:04, David Rowley wrote:
> On Thu, 29 Nov 2018 at 08:17, Steve Crawford
> wrote:
>> Both for my edification and as a potentially important documentation detail,
>> do operations that rebuild the table such as CLUSTER or pg_repack reclaim
>> the column space?
>
> I've never used
On Thu, 29 Nov 2018 at 08:17, Steve Crawford
wrote:
> Both for my edification and as a potentially important documentation detail,
> do operations that rebuild the table such as CLUSTER or pg_repack reclaim the
> column space?
I've never used pg_repack, but CLUSTER will reform the tuples so
On Thu, 29 Nov 2018 at 07:06, Peter Eisentraut
wrote:
>
> That last sentence about the dropped columns is confusing to me:
>
> +
> + Columns which have been dropped from the table also contribute to the
> + maximum column limit, although the dropped column values for newly
> +
On Wed, Nov 28, 2018 at 10:06 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> That last sentence about the dropped columns is confusing to me:
>
> +
> + Columns which have been dropped from the table also contribute to the
> + maximum column limit, although the
That last sentence about the dropped columns is confusing to me:
+
+ Columns which have been dropped from the table also contribute to the
+ maximum column limit, although the dropped column values for newly
+ created tuples are internally marked as NULL in the tuple's null
Thanks for looking at this.
On Thu, 15 Nov 2018 at 13:35, Tom Lane wrote:
> * I don't like inserting this as Appendix B, because that means
> renumbering appendixes that have had their same names for a *long*
> time; for instance the release notes have been Appendix E since
> we adopted the
David Rowley writes:
> [ v4-0001-Add-documentation-section-appendix-detailing-some.patch ]
A few nitpicky gripes on this -
* I don't like inserting this as Appendix B, because that means
renumbering appendixes that have had their same names for a *long*
time; for instance the release notes have
On 13 November 2018 at 19:46, John Naylor wrote:
> On 11/8/18, David Rowley wrote:
>> On 8 November 2018 at 22:46, Peter Eisentraut
>> wrote:
>>> Could you adjust this to use fewer capital letters, unless they start
>>> sentences or similar?
>>
>> Yeah. Changed in the attached.
>
> Looks good
On 11/8/18, David Rowley wrote:
> On 8 November 2018 at 22:46, Peter Eisentraut
> wrote:
>> Could you adjust this to use fewer capital letters, unless they start
>> sentences or similar?
>
> Yeah. Changed in the attached.
Looks good to me. Since there have been no new suggestions for a few
On 08/11/2018 04:13, David Rowley wrote:
> I added something along those lines in a note below the table. Likely
> there are better ways to format all this, but trying to detail out
> what the content should be first.
>
> Hopefully I I've addressed the other things mentioned too.
Could you
On 11/8/18, David Rowley wrote:
> On 8 November 2018 at 10:02, Robert Haas wrote:
>> It might be useful for some users to explain that certain things will
>> should work for values < X, may work for values between X and Y, and
>> will definitely not work above Y. Or maybe we can provide a
On 8 November 2018 at 10:02, Robert Haas wrote:
> IMHO, documenting that you can get up to 1600 integer columns but only
> 1002 bigint columns doesn't really help anybody, because nobody has a
> table with only one type of column, and people usually want to have
> some latitude to run ALTER TABLE
On Tue, Nov 6, 2018 at 6:01 AM John Naylor wrote:
> On 11/1/18, David Rowley wrote:
> > I've attached an updated patch, again it's just intended as an aid for
> > discussions at this stage. Also included the rendered html.
>
> Looks good so far. Based on experimentation with toasted columns, it
On 11/1/18, David Rowley wrote:
> I've attached an updated patch, again it's just intended as an aid for
> discussions at this stage. Also included the rendered html.
Looks good so far. Based on experimentation with toasted columns, it
seems the largest row size is 452GB, but I haven't tried
On 11/1/18, Andrew Gierth wrote:
> So (with 8k blocks) the limit on the number of non-null external-toasted
> columns is about 450, while you can have the full 1600 columns if they
> are integers or smaller, or just over 1015 bigints. But you can have
> 1600 text columns if they average 4 bytes
> "Nasby," == Nasby, Jim writes:
>> I did try a table with 1600 text columns then inserted values of
>> several kB each. Trying with BIGINT columns the row was too large
>> for the page. I've never really gotten a chance to explore these
>> limits before, so I guess this is about the
On 11/1/18, Nasby, Jim wrote:
> Hmm… 18 bytes doesn’t sound right, at least not for the Datum. Offhand I’d
> expect it to be the small (1 byte) varlena header + an OID (4 bytes). Even
> then I don’t understand how 1600 text columns would work; the data area of a
> tuple should be limited to ~2000
> On Oct 31, 2018, at 5:22 PM, David Rowley
> wrote:
>
> On 1 November 2018 at 04:40, John Naylor wrote:
>> Thanks for doing this. I haven't looked at the rendered output yet,
>> but I have some comments on the content.
>>
>> + Maximum Relation Size
>> + 32 TB
>> + Limited by
On 1 November 2018 at 04:40, John Naylor wrote:
> Thanks for doing this. I haven't looked at the rendered output yet,
> but I have some comments on the content.
>
> + Maximum Relation Size
> + 32 TB
> + Limited by 2^32 pages per relation
>
> I prefer "limited to" or "limited by the
On 10/30/18, David Rowley wrote:
> On 26 October 2018 at 11:40, Haribabu Kommi
> wrote:
>> On Fri, Oct 26, 2018 at 9:30 AM David Rowley
>>
>> wrote:
>>>
>>> For a long time, we documented our table size, max columns, max column
>>> width limits, etc. in https://www.postgresql.org/about/ , but
On 26 October 2018 at 11:40, Haribabu Kommi wrote:
> On Fri, Oct 26, 2018 at 9:30 AM David Rowley
> wrote:
>>
>> For a long time, we documented our table size, max columns, max column
>> width limits, etc. in https://www.postgresql.org/about/ , but that
>> information seems to have now been
+1 for inclusion in docs.
On Fri, Oct 26, 2018 at 4:00 AM David Rowley
wrote:
> For a long time, we documented our table size, max columns, max column
> width limits, etc. in https://www.postgresql.org/about/ , but that
> information seems to have now been removed. The last version I can
> find
On 2018-Oct-26, David Rowley wrote:
> For a long time, we documented our table size, max columns, max column
> width limits, etc. in https://www.postgresql.org/about/ , but that
> information seems to have now been removed. The last version I can
> find with the information present is back in
From: David Rowley [mailto:david.row...@2ndquadrant.com]
> I think it's a bit strange that we don't have this information fairly
> early on in the official documentation. I only see a mention of the
> 1600 column limit in the create table docs. Nothing central and don't
> see mention of 32 TB
On Fri, Oct 26, 2018 at 9:30 AM David Rowley
wrote:
> For a long time, we documented our table size, max columns, max column
> width limits, etc. in https://www.postgresql.org/about/ , but that
> information seems to have now been removed. The last version I can
> find with the information
For a long time, we documented our table size, max columns, max column
width limits, etc. in https://www.postgresql.org/about/ , but that
information seems to have now been removed. The last version I can
find with the information present is back in April this year. Here's a
link to what we had:
27 matches
Mail list logo
