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 wis
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?
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 qu
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 t
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
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
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 t
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
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? If
so, is the info easily available?
Thanks,
HH
--
H. Hall
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 abi
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
Sent: Wed May 21 07:37:49 2008
Subject: Re: [PERFORM] Posible pl
A Dimecres 21 Maig 2008, Albert Cervera Areny va escriure:
> 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 > 158
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 wa
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, 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)
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 wh
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 rep
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 >
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 you
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 to
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 certa
21 matches
Mail list logo
