Robins Tharakan wrote:
Hi,
Now what I wanted to ask was whether its any different to have the
primary-keys in such master tables as text/varchar rather than integer ?
i.e. Can I use a character varying(10) and use the text 'million' /
'billion' instead of a serial / integer type ?
One
Robins Tharakan wrote:
Hi,
I am currently designing a database and wanted to know something that may
sound trivial, but I thought its still good to confirm before dumping
millions of rows in it.
The design requires a few master tables with very limited rows, for e.g.
currency_denomination
Craig Ringer wrote:
p.s.: I am not as much concerned with the size that it'd take on the data
tables, as much as the fact that the select / insert performances
shouldn't
suffer. However, if that increase in size (per data record) may make a
considerable impact on the performance, I would
Shane Ambler wrote:
Size can affect performance as much as anything else. In your case of
limited rows it will make little difference, though the larger table
with millions of rows will have this key entered for each row and be
indexed as the foreign key.
The real question is how you want
On May 21, 2008, at 12:33 AM, Shane Ambler wrote:
Size can affect performance as much as anything else.
For a brief moment, I thought the mailing list had been spammed. ;-)
J. Andrew Rogers
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to
I've got a query similar to this:
select * from t1, t2 where t1.id 158507 and t1.id = t2.id;
That took 84 minutes (the query was a bit longer but this is the part that
made the difference) after a little change the query took ~1 second:
select * from t1, t2 where t1.id 158507 and t2.id
Hello,
Small update on this problem:
Wouter Verhelst came to help debugging, and he determined that the 2 seconds
were spent planning the query and not executing the query. (executing the
query is quick as seen in the query plan).
To avoid replanning this query all the time, Wouter suggest
Albert Cervera Areny wrote:
I've got a query similar to this:
select * from t1, t2 where t1.id 158507 and t1.id = t2.id;
That took 84 minutes (the query was a bit longer but this is the part that
made the difference) after a little change the query took ~1 second:
select * from t1, t2
A Dimecres 21 Maig 2008, Richard Huxton va escriure:
Albert Cervera Areny wrote:
I've got a query similar to this:
select * from t1, t2 where t1.id 158507 and t1.id = t2.id;
That took 84 minutes (the query was a bit longer but this is the part
that made the difference) after a
A Dimecres 21 Maig 2008, Richard Huxton va escriure:
Albert Cervera Areny wrote:
I've got a query similar to this:
select * from t1, t2 where t1.id 158507 and t1.id = t2.id;
That took 84 minutes (the query was a bit longer but this is the part
that made the difference) after a little
A Dimecres 21 Maig 2008, Mark Mielke va escriure:
A Dimecres 21 Maig 2008, Richard Huxton va escriure:
Albert Cervera Areny wrote:
I've got a query similar to this:
select * from t1, t2 where t1.id 158507 and t1.id = t2.id;
That took 84 minutes (the query was a bit longer but this
The problem is that the implied join predicate is not being propagated. This
is definitely a planner deficiency.
- Luke
- Original Message -
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
To: pgsql-performance@postgresql.org pgsql-performance@postgresql.org
Sent: Wed May 21 07:37:49 2008
Luke Lonergan wrote:
The problem is that the implied join predicate is not being
propagated. This is definitely a planner deficiency.
IIRC only equality conditions are propagated and gt, lt, between aren't.
I seem to remember that the argument given was that the cost of
checking for the
On Wed, May 21, 2008 at 10:10 AM, H. Hall [EMAIL PROTECTED] wrote:
Does anyone know if there is a source that provides Big O notation for
postgres's aggregate functions and operations? For example is count(*) =
O(1) or O(n)?
I don't know of any document containing the complexity of each
Jonah H. Harris wrote:
On Wed, May 21, 2008 at 10:10 AM, H. Hall [EMAIL PROTECTED] wrote:
Does anyone know if there is a source that provides Big O notation for
postgres's aggregate functions and operations? For example is count(*) =
O(1) or O(n)?
I don't know of any document containing the
On Wed, 21 May 2008 15:09:49 +0200, Richard Huxton [EMAIL PROTECTED]
wrote:
Luke Lonergan wrote:
The problem is that the implied join predicate is not being
propagated. This is definitely a planner deficiency.
IIRC only equality conditions are propagated and gt, lt, between aren't.
I
On Wed, 21 May 2008 16:10:53 +0200, H. Hall [EMAIL PROTECTED]
wrote:
Does anyone know if there is a source that provides Big O notation for
postgres's aggregate functions and operations? For example is count(*)
= O(1) or O(n)?
Do the developers for postgres use Big O when selecting
A Dimecres 21 Maig 2008, Richard Huxton va escriure:
Luke Lonergan wrote:
The problem is that the implied join predicate is not being
propagated. This is definitely a planner deficiency.
IIRC only equality conditions are propagated and gt, lt, between aren't.
I seem to remember that the
I think you're looking to return set of record or something like that.
On Wed, May 21, 2008 at 4:37 AM, Frank Dekervel
[EMAIL PROTECTED] wrote:
Hello,
Small update on this problem:
Wouter Verhelst came to help debugging, and he determined that the 2 seconds
were spent planning the query and
PFC wrote:
On Wed, 21 May 2008 16:10:53 +0200, H. Hall wrote:
Does anyone know if there is a source that provides Big O notation
for postgres's aggregate functions and operations? For example is
count(*) = O(1) or O(n)?
Do the developers for postgres use Big O when selecting algorithms?
On Wed, May 21, 2008 at 1:27 PM, J. Andrew Rogers [EMAIL PROTECTED]
wrote:
On May 21, 2008, at 12:33 AM, Shane Ambler wrote:
Size can affect performance as much as anything else.
For a brief moment, I thought the mailing list had been spammed. ;-)
And that sums up why I wish to thank
21 matches
Mail list logo
