On Tue, Oct 12, 2010 at 10:28 PM, Samuel Gendler
wrote:
>
>
> On Tue, Sep 21, 2010 at 4:30 PM, Tom Lane wrote:
>>
>> Ogden writes:
>> > SELECT tr.id, tr.sid
>> > FROM
>> > test_registration tr,
>> > INNER JOIN test_registration_result r on (tr.id =
>> > r.test
On Tue, Sep 21, 2010 at 4:30 PM, Tom Lane wrote:
> Ogden writes:
> > SELECT tr.id, tr.sid
> > FROM
> > test_registration tr,
> > INNER JOIN test_registration_result r on (tr.id =
> r.test_registration_id)
> > WHERE.
> >
> tr.test_administration_id=
On Sep 21, 2010, at 6:30 PM, Tom Lane wrote:
> Ogden writes:
>> SELECT tr.id, tr.sid
>>FROM
>>test_registration tr,
>>INNER JOIN test_registration_result r on (tr.id =
>> r.test_registration_id)
>>WHERE.
>>
>> tr.test_administration_id
On Wed, Sep 22, 2010 at 9:36 AM, Ogden wrote:
>
> On Sep 21, 2010, at 2:34 PM, Ogden wrote:
>
>>
>> On Sep 21, 2010, at 2:16 PM, Greg Smith wrote:
>>
>>> Joshua D. Drake wrote:
PostgreSQL's defaults are based on extremely small and some would say
(non production) size databases. As a mat
On Sep 22, 2010, at 6:36 AM, Ogden wrote:
>
> On Sep 21, 2010, at 2:34 PM, Ogden wrote:
>
>>
>> On Sep 21, 2010, at 2:16 PM, Greg Smith wrote:
>>
>>> Joshua D. Drake wrote:
PostgreSQL's defaults are based on extremely small and some would say
(non production) size databases. As a ma
On Sep 21, 2010, at 2:34 PM, Ogden wrote:
>
> On Sep 21, 2010, at 2:16 PM, Greg Smith wrote:
>
>> Joshua D. Drake wrote:
>>> PostgreSQL's defaults are based on extremely small and some would say
>>> (non production) size databases. As a matter of course I always
>>> recommend bringing seq_page_
Ogden writes:
> SELECT tr.id, tr.sid
> FROM
> test_registration tr,
> INNER JOIN test_registration_result r on (tr.id =
> r.test_registration_id)
> WHERE.
>
> tr.test_administration_id='32a22b12-aa21-11df-a606-96551e8f4e4c'::uuid
>
Greg Smith writes:
> and the query optimizer needs to be careful about what it does and
> doesn't pull from disk. If that's not the case, like here where there's
> 8GB of RAM and a 7GB database, dramatic reductions to both seq_page_cost
> and random_page_cost can make sense. Don't be afraid t
On Sep 21, 2010, at 2:16 PM, Greg Smith wrote:
> Joshua D. Drake wrote:
>> PostgreSQL's defaults are based on extremely small and some would say
>> (non production) size databases. As a matter of course I always
>> recommend bringing seq_page_cost and random_page_cost more in line.
>>
>
> Also
Joshua D. Drake wrote:
PostgreSQL's defaults are based on extremely small and some would say
(non production) size databases. As a matter of course I always
recommend bringing seq_page_cost and random_page_cost more in line.
Also, they presume that not all of your data is going to be in memo
On Tue, 2010-09-21 at 14:02 -0500, Ogden wrote:
> How odd, I set the following:
>
> seq_page_cost = 1.0
> random_page_cost = 2.0
>
> And now the query runs in milliseconds as opposed to 14 seconds. Could this
> really be the change? I am running ANALYZE now - how often is it recommended
How odd, I set the following:
seq_page_cost = 1.0
random_page_cost = 2.0
And now the query runs in milliseconds as opposed to 14 seconds. Could this
really be the change? I am running ANALYZE now - how often is it recommended to
do this?
Thank you
Ogden
On Sep 21, 2010, at 1:51 PM,
On 2010-09-21 20:21, Ogden wrote:
I assume you mean random_page_cost? It is currently set to 4.0 - is it better
to increase or decrease this value?
Should be lowered to a bit over seq_page_cost.. and more importantly..
you should
make sure that you have updated your statistics .. run "A
I assume you mean random_page_cost? It is currently set to 4.0 - is it better
to increase or decrease this value?
Thank you
Ogden
On Sep 21, 2010, at 1:06 PM, Kenneth Marshall wrote:
> You DB is more than likely cached. You should adjust your
> page costs to better reflect reality and then t
You DB is more than likely cached. You should adjust your
page costs to better reflect reality and then the planner
can make more accurate estimates and then choose the proper
plan.
Cheers,
Ken
On Tue, Sep 21, 2010 at 12:32:01PM -0500, Ogden wrote:
> Hello,
>
> I have received some help from the
Hello,
I have received some help from the IRC channel, however, the problem still
exists. When running the following query with enable_seqscan set to 0, it takes
less than a second, whereas with it set to 1, the query returns in 14 seconds.
The machine itself has 8GB Ram and is running PostgreS
16 matches
Mail list logo
