On Fri, Nov 19, 2010 at 1:41 PM, Scott Ribe wrote:
> And I tried to make the "it only involves a single t1 and matches a single
> partition" more explicit, but this didn't do it either:
>
> explain with tbl as (select id from t1 where name = 'foo')
> select * from t1, t2 where t1.id = t2.t1_id an
On Monday 23 June 2008 15:45:22 Kynn Jones wrote:
> On Mon, Jun 23, 2008 at 2:21 PM, Steve Atkins <[EMAIL PROTECTED]> wrote:
> > In real use you're unlikely to hit any limits, theoretical or practical,
> > but if you start to use a silly number of tables and so on you're likely
> > to hit performan
Thomas Kellerer wrote:
Steve Atkins wrote on 23.06.2008 20:21:
> In real use you're unlikely to hit any limits, theoretical or practical,
I imagine that the 1GB column-value limit is something that could be
reached though. Especially for BLOB (aka bytea) or CLOB (aka text) columns.
No, since
Steve Atkins wrote on 23.06.2008 20:21:
> In real use you're unlikely to hit any limits, theoretical or practical,
I imagine that the 1GB column-value limit is something that could be reached
though. Especially for BLOB (aka bytea) or CLOB (aka text) columns.
Thomas
--
Sent via pgsql-genera
On Mon, Jun 23, 2008 at 2:45 PM, Kynn Jones <[EMAIL PROTECTED]> wrote:
> Actually, the DB I have in mind would certainly be approaching "silly
> territory." I'm looking at a schema with around 10 thousand tables (or
> views).
What kind of app would require such a schema? Just curious...
--
Sent
"Kynn Jones" <[EMAIL PROTECTED]> writes:
> Actually, the DB I have in mind would certainly be approaching "silly
> territory." I'm looking at a schema with around 10 thousand tables (or
> views). Unfortunately, as far as I can tell,
> http://www.postgresql.org/about/ says nothing about maximum nu
On Mon, Jun 23, 2008 at 2:21 PM, Steve Atkins <[EMAIL PROTECTED]> wrote:
>
> In real use you're unlikely to hit any limits, theoretical or practical,
> but if you start to use a silly number of tables and so on you're likely to
> hit performance issues eventually. I'm not sure where that threshold
On Mon, 2008-06-23 at 11:21 -0700, Steve Atkins wrote:
>
>
> http://www.postgresql.org/about/ has some of the theoretical limits.
>
> In real use you're unlikely to hit any limits, theoretical or
> practical, but if you start to use a silly number of tables and so
> on
> you're likely to hi
http://www.postgresql.org/about/
On Mon, 2008-06-23 at 13:56 -0400, Kynn Jones wrote:
>
>
>
>
>
>
>
> How can I find the limits (if any) on things such as the maximum
> number of tables, views, indices, columns-per-table, size of database,
> etc.?
>
>
> (At the moment I'm particularly int
On Jun 23, 2008, at 10:56 AM, Kynn Jones wrote:
How can I find the limits (if any) on things such as the maximum
number of tables, views, indices, columns-per-table, size of
database, etc.?
(At the moment I'm particularly interested any limits that my exist
on the numbers of tables
On Dec 15, 2007, at 8:29 PM, Bruce Momjian wrote:
[EMAIL PROTECTED] wrote:
Hi All.
My question is simple and plain: Are there some limit in the
number of
database operations between a BEGIN statement and a COMMIT statement?
Yes, there is a command counter that is incremented for every com
[EMAIL PROTECTED] wrote:
> Hi All.
> My question is simple and plain: Are there some limit in the number of
> database operations between a BEGIN statement and a COMMIT statement?
Yes, there is a command counter that is incremented for every command
between BEGIN and COMMIT. It can't exceed 4 bil
<[EMAIL PROTECTED]> writes:
> Hi All.
> My question is simple and plain: Are there some limit in the number of
> database operations between a BEGIN statement and a COMMIT statement?
The most relevant limitation is that the whole body has to fit in 1GB.
You can also only execute 4 billion statem
[EMAIL PROTECTED] (Bob Pawley) writes:
> Are there any practical limits to the number of functions and
> triggers that can be applied to any particular table??
I'd expect it to be rather like Perlis' assertion about procedures
with lots of parameters...
--
let name="cbbrowne" and tld="ntlug.org"
Joachim Zobel schrob:
> Am Samstag, den 04.06.2005, 15:22 -0500 schrieb Bruno Wolff III:
>> On Sat, Jun 04, 2005 at 21:53:24 +0200,
>> Joachim Zobel <[EMAIL PROTECTED]> wrote:
>> > So WITH will allow recursion so I can walk the graph, right? Does this
>> > mean I can recursively join until a ter
Am Samstag, den 04.06.2005, 15:22 -0500 schrieb Bruno Wolff III:
> On Sat, Jun 04, 2005 at 21:53:24 +0200,
> Joachim Zobel <[EMAIL PROTECTED]> wrote:
> > So WITH will allow recursion so I can walk the graph, right? Does this
> > mean I can recursively join until a terminating condition is reached
On Sat, Jun 04, 2005 at 21:53:24 +0200,
Joachim Zobel <[EMAIL PROTECTED]> wrote:
> Am Samstag, den 04.06.2005, 07:38 -0500 schrieb Bruno Wolff III:
> > On Sat, Jun 04, 2005 at 11:31:02 +0200,
> > Joachim Zobel <[EMAIL PROTECTED]> wrote:
> > >
> > > ... And it seems that
> > > a plain SELECT th
Am Samstag, den 04.06.2005, 07:38 -0500 schrieb Bruno Wolff III:
> On Sat, Jun 04, 2005 at 11:31:02 +0200,
> Joachim Zobel <[EMAIL PROTECTED]> wrote:
> >
> > ... And it seems that
> > a plain SELECT that tells me if a path exists is not possible...
>
> When 'WITH' gets implemented then you shou
On Sat, Jun 04, 2005 at 11:31:02 +0200,
Joachim Zobel <[EMAIL PROTECTED]> wrote:
>
> These are both things I want to avoid. I am not trying to solve a real
> world problem, I want to understand the limits of SQL. And it seems that
> a plain SELECT that tells me if a path exists is not possible.
Am Donnerstag, den 02.06.2005, 12:46 -0700 schrieb Ben:
> You mean, you want to be able to say something like:
>
> select isConnected(a,b)
>
> and get back a true/false, or maybe the path?
>
> That seems quite doable in SQL, assuming you either store those results
> and simply use sql to retrie
Is anybody else thinking about the limits of SQL? As often I am probably
not the first to ask these questions. Any pointers?
Joe Celko (sp?) has a couple of books on this subject, SQL for Smarties. I
don't recall if he talks about graphs, but does discuss queries on tree
relationships.
I've go
> Is anybody else thinking about the limits of SQL? As often I am probably
> not the first to ask these questions. Any pointers?
Joe Celko (sp?) has a couple of books on this subject, SQL for Smarties. I
don't recall if he talks about graphs, but does discuss queries on tree
relationships.
--
S
A couple of links:
http://www.dbazine.com/ofinterest/oi-articles/celko24
http://www.dbmsmag.com/9603d06.html
On Jun 2, 2005, at 2:33 AM, Joachim Zobel wrote:
Hi.
I am looking for a way to write a SELECT that finds connectivity
components of a graph or at least for one that given two nodes
de
I'm not sure if it's relevant to your question
http://www-2.cs.cmu.edu/~cache/pg_graph/
pg_graph provides a way of handling graph-based data structures within
the relational database PostgreSQL. In particular, it provides a convenient
means of inserting graphs as BLOB-like objects in the RDBMS.
You mean, you want to be able to say something like:
select isConnected(a,b)
and get back a true/false, or maybe the path?
That seems quite doable in SQL, assuming you either store those results
and simply use sql to retrieve them, or use a stored proc to compute the
result each time.
On Thu,
Marcos Barreto de Castro <[EMAIL PROTECTED]> writes:
> 1 - How many tuples can be returned as a result of a
> query using a CURSOR? (Is it possible to do a SELECT
> * on a table that has 2 million records and OPEN a
> CURSOR for that SELECT and show all records'contents
> using FETCH FORWARD, for
Hi,
> Is there a way to select only a range of rows from a table, using
> a command
> like:
>
> SELECT * FROM table WHERE where_statement LIMIT 50,100;
Assuming you use a "Order By" clause to make sure you got the records in the
appropriate order there is a patch file in the "patches" directory
On Sat, 9 Jan 1999, Fabrice Scemama wrote:
// Is there a way to select only a range of rows from a table, using a command
// like:
//
// SELECT * FROM table WHERE where_statement LIMIT 50,100;
That doesn't make sense in a relational database by itself since
it's not guaranteed to retu
28 matches
Mail list logo
