Hi,
What is the maximum row size for PostgreSQL?
http://www.postgresql.org/about/ says 1.6 TB
http://www.postgresql.org/docs/faqs.FAQ.html says 400 GB.
Both may be true in fact, depending on block size. But which one is the
accurate answer? I'm confused.
Regards,
--
Devrim GÜNDÜZ
PostgreSQL
Hello
I am testing:
postgres=# create domain nb int check(value 10);
CREATE DOMAIN
postgres=# select 11::nb;
nb
11
(1 row) -- ok
postgres=# select -11::nb;
?column?
--
-11
(1 row) -- ughh
postgres=# select (-11)::nb; -- I understand
ERROR: value for domain nb violates
Devrim GÜNDÜZ [EMAIL PROTECTED] writes:
What is the maximum row size for PostgreSQL?
http://www.postgresql.org/about/ says 1.6 TB
I think this comes from the maximum of 1600 columns times the maximum of 1GB
per (toasted) datum.
However 1600 toasted datums won't fit on an 8k page. Each
Hi,
it seems a lot of work is still being done on 8.3. But we are in feature
freeze, aren't we? I'm wondering because I'm sitting on some major
changes to ecpg (real prepare amongst them) but haven't committed these
because of the freeze. However, it looks as if new patches are still
coming in.
Gregory Stark [EMAIL PROTECTED] writes:
... it's kind
of pie-in-the-sky since it depends on every column being toasted (and not
compressed). It's much more normal to have some columns be quite large and
others more normal sized or different data types.
Yeah. I think those numbers should
Pavel Stehule [EMAIL PROTECTED] writes:
postgres=# select -11::nb;
The operator precedence table at
http://developer.postgresql.org/pgdocs/postgres/sql-syntax-lexical.html#SQL-PRECEDENCE
says perfectly clearly that :: binds more tightly than -.
regards, tom lane
Michael Meskes [EMAIL PROTECTED] writes:
it seems a lot of work is still being done on 8.3. But we are in feature
freeze, aren't we? I'm wondering because I'm sitting on some major
changes to ecpg (real prepare amongst them) but haven't committed these
because of the freeze.
Well, we are in
accept 92DE-7B78-4153
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Am Sonntag, 12. Aug 2007, 18:36:47 +0200 schrieb Bertram Scharpf:
Good bye!
I just forgot to refer to--of course--the German knight of
the iron hand.
Bertram
--
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-scharpf.de
---(end of
2007/8/13, Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
postgres=# select -11::nb;
The operator precedence table at
http://developer.postgresql.org/pgdocs/postgres/sql-syntax-lexical.html#SQL-PRECEDENCE
says perfectly clearly that :: binds more tightly than -.
So I was testing my fix for the problem noted here:
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00196.php
and promptly found *another* bug. To wit, that repair_frag calls
HeapTupleSatisfiesVacuum without bothering to acquire any buffer
content lock. This results in an Assert failure
Bertram,
Just so you know, there is a site for external projects associated with
PostgreSQL which are not part of the core code:
www.pgfoundry.org
You are quite welcome to propose your connect-by code as a project on
pgFoundry. This is how many new features start out before acceptance anyway.
Josh,
I think what you are suggesting is something like this:
-- begin SQL --
core=# CREATE TABLE temp_x( x_id BIGINT PRIMARY KEY, x_info VARCHAR(16) NOT
NULL DEFAULT 'x_info');
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index temp_x_pkey
for table temp_x
CREATE TABLE
core=# CREATE
Tom Lane wrote:
But to get to the point: the urgency of testing the patch more
extensively has just moved up a full order of magnitude, IMHO anyway.
I muttered something in the other thread about providing a buildfarm
option to run the regression tests with synchronous_commit off. That
would
Tom Lane [EMAIL PROTECTED] writes:
But to get to the point: the urgency of testing the patch more
extensively has just moved up a full order of magnitude, IMHO anyway.
I muttered something in the other thread about providing a buildfarm
option to run the regression tests with
Andrew Dunstan [EMAIL PROTECTED] writes:
I have some ideas about testing configuration items. Doing all our tests
with the default config is not ideal, I think. Essentially we'd put up a
server that would have sets of branch, list-of-config-lines. The
client would connect to the server if
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I propose that we actually set synchronous_commit
off by default for the next little while --- at least up to 8.3beta1,
maybe until we approach the RC point. That will ensure that every
buildfarm machine is exercising
Hi All,
Tomas Kovarik and I have presented at PGCon 2007 in Ottawa
the ideas about other possible optimizer algorithms to be used
in PostgreSQL.
We are quite new to PostgreSQL project so it took us some
time to go through the sources end explore the possibilities
how things could be
Julius Stroffek wrote:
Hi All,
Tomas Kovarik and I have presented at PGCon 2007 in Ottawa
the ideas about other possible optimizer algorithms to be used
in PostgreSQL.
We are quite new to PostgreSQL project so it took us some
time to go through the sources end explore the possibilities
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I have some ideas about testing configuration items. Doing all our tests
with the default config is not ideal, I think. Essentially we'd put up a
server that would have sets of branch, list-of-config-lines. The
client would connect
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Julius Stroffek wrote:
There is a proposal attached to this mail about the interface
we would like to implement for switching between different
optimizers. Please review it and provide a feedback to us.
hmm - how does is that proposal different
Stefan,
thanks for pointing this out. I missed this change.
We would like to place the hooks to a different place in the planner and
we would like to just replace the non-deterministic algorithm searching
for the best order of joins and keep the rest of the planner untouched.
I am not quite
Julius Stroffek [EMAIL PROTECTED] writes:
I understood that if the user creates his own implementation of the
planner which can be stored in some external library, he have to provide
some C language function as a hook activator which will assign the
desired value to the planner_hook
Gregory Stark wrote:
When autovacuum vacuums a table it always vacuums the toast table as well. Is
there any particular reason to consider the two together? I think this may
just be a holdover from the interactive command which considers them together
because the toast table is supposed to be
Alvaro Herrera [EMAIL PROTECTED] writes:
I think there is some special code in tqual.c that skips some checks
assuming that the toast table is vacuumed at the same time as the main
heap.
I don't believe there is any such connection. We do use a special
snapshot for toast tables, but it's only
Tom,
Also, while we might accept
a small hook-function patch for 8.3, there's zero chance of any of that
other stuff making it into this release cycle.
I don't think anyone was thinking about 8.3. This is pretty much 8.4
stuff; Julius is just raising it now becuase they don't want to go
On 8/14/07, Bertram Scharpf [EMAIL PROTECTED] wrote:
I just forgot to refer to--of course--the German knight of
the iron hand.
Prima donna? Not quite done yet?
Denk mal nach. Kritik kann wohl begruendet sein. Und was die
Jungs gesagt haben war sowohl inhaltlich als auch von Votrag
her
Josh Berkus [EMAIL PROTECTED] writes:
Tom,
Also, while we might accept
a small hook-function patch for 8.3, there's zero chance of any of that
other stuff making it into this release cycle.
I don't think anyone was thinking about 8.3. This is pretty much 8.4
stuff; Julius is just raising
Jason,
Which brings us back to the original issue. If I decide to stick with
the current implementation and not improve our existing partitioning
mechanisms to scale to 100,000 partitions, I could do something like:
Maintain 2 copies of the parent table (partitioned by 256).
Inherit from
Heikki Linnakangas wrote:
Oleg Bartunov wrote:
On Wed, 8 Aug 2007, Bruce Momjian wrote:
Heikki Linnakangas wrote:
If I understood correctly, the basic issue is that a tsvector datum
created using configuration A is incompatible with a tsquery datum
created using configuration B, in the
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Removing the default configuration setting altogether removes the 2nd
problem, but that's not good from a usability point of view. And it
doesn't solve the general issue, you can still do things like:
SELECT * FROM
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Brendan Jurd wrote:
Hello,
As discussed on -hackers, I've done some refactoring work on
32 matches
Mail list logo
