Josh Berkus writes:
> SELECT COUNT(*)
> FROM "user"
> INNER JOIN "house"
> ON ("user"."house_id" = "house"."id")
> LEFT OUTER JOIN "district"
> ON ("house"."district_id" = "district"."id")
> WHERE ("user"."status" = 0
> AND ("district"."update_status" = 2
> OR "dis
On Thu, Aug 16, 2012 at 2:40 AM, J Ramesh Kumar wrote:
Ahhh but updates are the basically delete / inserts in disguise, so if
there's enough, then yes, vacuum full would make a difference.
>
> The table which get update has very less data ie, only has 900 rows. Out of
> 10500 tables, onl
Hi,
On 16 August 2012 15:40, J Ramesh Kumar wrote:
> As you said, MySQL with MyISAM is better choice for my app. Because I don't
> need transaction/backup. May be I'll try with InnoDB and find the disk
> write/space difference. Is there any similar methods available in postgresql
> like MyISAM en
On Thu, Aug 16, 2012 at 1:30 AM, J Ramesh Kumar wrote:
> # To avoid freqent autovacuum
> autovacuum_freeze_max_age = 20
> vacuum_freeze_min_age = 1000
> vacuum_freeze_table_age = 15000
>
In general, I'm no expert, but I've heard, increasing freeze_max_age isn't
wise. It's there to
Dear Scott Marlowe,
Thanks for the details.
As you said, MySQL with MyISAM is better choice for my app. Because I don't
need transaction/backup. May be I'll try with InnoDB and find the disk
write/space difference. Is there any similar methods available in
postgresql like MyISAM engine ?
>>> Ahh
Please use plain text on the list, some folks don't have mail readers
that can handle html easily.
On Wed, Aug 15, 2012 at 10:30 PM, J Ramesh Kumar wrote:
>
> Hi David Barton,
>
> Please find the information below.
>
>> Are you able to provide a table schema?
>
>
> There are 109 different types o
Hi David Barton,
Please find the information below.
Are you able to provide a table schema?
There are 109 different types of table. I am maintaining some tables are
daily tables and some tables are ID based. So totally we have created
around 350 tables and dropped around 350 tables. I will drop
Hi Ramesh,
Are you able to provide a table schema? Were you using MyISAM or InnoDB
on MySQL?
If you back up the database & restore clean, what is the size comparison
of the database filed on the restored copy to the existing one? It may
be full of empty tuples. Is there any period where y
Hi,
My application has high data intensive operations (high number of inserts
1500 per sec.). I switched my application from MySQL to PostgreSQL. When I
take performance comparison report between mysql and pgsql, I found that,
there are huge difference in disk writes and disk space taken. Below st
> If you can show us the anonymized query plan, why not the anonymized query?
> It doesn't look like it could be all that complicated.
It's not:
SELECT COUNT(*)
FROM "user"
INNER JOIN "house"
ON ("user"."house_id" = "house"."id")
LEFT OUTER JOIN "district"
ON ("house"."district_id" =
Josh Berkus writes:
> On 8/15/12 1:51 PM, Tom Lane wrote:
>> Maybe you had better show us the actual query, and the table/index
>> definitions. Because it's sure making odd choices here. This seems
>> like the wrong join order altogether ...
> We'll need to do that off-list for confidentiality
On 08/15/12 14:05, Josh Berkus wrote:
>
>> That actually makes sense to me. Cluster the rows covered by that
>> index, let the rest fall where they may. I'm typically only accessing
>> the rows covered by that index, so I'd get the benefit of the cluster
>> command but wouldn't have to spend cycle
On 8/15/12 1:51 PM, Tom Lane wrote:
> Christophe Pettus writes:
>> On Aug 13, 2012, at 7:11 PM, Tom Lane wrote:
>>> The whole thing looks a bit weird to me --- why did it not use a
>>> nestloop join with inner indexscan on charlie? With 7000 rows on the
>>> other side, the estimated cost for that
> That actually makes sense to me. Cluster the rows covered by that
> index, let the rest fall where they may. I'm typically only accessing
> the rows covered by that index, so I'd get the benefit of the cluster
> command but wouldn't have to spend cycles doing the cluster for rows I
> don't care
Christophe Pettus writes:
> On Aug 13, 2012, at 7:11 PM, Tom Lane wrote:
>> The whole thing looks a bit weird to me --- why did it not use a
>> nestloop join with inner indexscan on charlie? With 7000 rows on the
>> other side, the estimated cost for that shouldn't have been more than
>> about 30
On Aug 13, 2012, at 7:11 PM, Tom Lane wrote:
> The whole thing looks a bit weird to me --- why did it not use a
> nestloop join with inner indexscan on charlie? With 7000 rows on the
> other side, the estimated cost for that shouldn't have been more than
> about 3 ...
Here's the same query w
On Tue, Aug 14, 2012 at 1:29 PM, k...@rice.edu wrote:
>
> It probably has to do with the fact that a conditional index, does
> not include every possible row in the table. Although, a "cluster" of
> the matching rows and then leave the rest in place, should work. How
> is that for hand-waving. :)
17 matches
Mail list logo
