One parent table, having 100 child tables.
In this scenario we observed that delete and update are taking more memory
for preparing a plan
If the system under peak i am getting out of memory issue.
i.e
Select on parent table is using memory - 331456 in message context
Delete on parent ta
On Thu, Dec 13, 2012 at 9:38 AM, Amitabh Kant wrote:
> Hi
>
> Our scripts automatically add "LIMIT ALL" & "OFFSET 0" to every select query
> if no values are passed on for these parameters. I remember reading through
> the mailing list that it's better not to pass them if they are not needed as
>
Hi
Our scripts automatically add "LIMIT ALL" & "OFFSET 0" to every select
query if no values are passed on for these parameters. I remember reading
through the mailing list that it's better not to pass them if they are not
needed as they add a cost to the query plan. Is this the case, or am i
loo
Huan Ruan wrote:
> is a lot slower than a nested loop join.
Giving actual numbers is more useful than terms like "a lot". Even
better is to provide the output of EXPLAIN ANALYZZE rather than
just EXPLAIN. This shows estimates against actual numbers, and give
timings. For more suggestions see this
On 13/12/2012 12:22 AM, Niels Kristian Schjødt wrote:
> Well, In fact I do (as you can see from my configuration). I have a
> similar server running with hot standby replication - and it runs two
> 3T HDD in a RAID1 array.
>
> So - is it still very bad if I choose to put four intel 520 disks in a
>
On 12/12/2012 05:12 PM, Andrew Dunstan wrote:
On 12/12/2012 04:32 PM, Tom Lane wrote:
Andrew Dunstan writes:
A client is testing a migration from 9.1 to 9.2, and has found that a
large number of queries run much faster if they use index-only scans.
However, the only way he has found to get s
On 12/12/2012 04:32 PM, Tom Lane wrote:
Andrew Dunstan writes:
A client is testing a migration from 9.1 to 9.2, and has found that a
large number of queries run much faster if they use index-only scans.
However, the only way he has found to get such a plan is by increasing
the seq_page_cost to
A client is testing a migration from 9.1 to 9.2, and has found that a
large number of queries run much faster if they use index-only scans.
However, the only way he has found to get such a plan is by increasing
the seq_page_cost to insanely high levels (3.5). Is there any approved
way to enco
On 12/12/2012 03:24 PM, Alejandro Carrillo wrote:
Hi,
Anybody knows how to create a table using a table file? It isn't a
fdw, is a file that compose the table in postgresql and get with the
pg_relation_filepath function. Ex:
select pg_relation_filepath('pg_proc');
Anybody knows a JDBC or a
Hi,
Anybody knows how to create a table using a table file? It isn't a fdw, is a
file that compose the table in postgresql and get with the pg_relation_filepath
function. Ex:
select pg_relation_filepath('pg_proc');
Anybody knows a JDBC or a multiplatform code that let read the delete rows of a
Hi,
On Wed, Dec 12, 2012 at 8:26 AM, Alejandro Carrillo wrote:
> Anybody knows a JDBC or a multiplatform code that let read the delete rows
> of a table without writing of a table file?
> Anybody knows how to create a table using a table file?
I am not sure what you mean but may be one of this l
Is there a performance downside to setting track_activity_query_size to
a significantly larger value than the default 1024 (say 10240), given
that there's plenty of memory to spare?
cheers
andrew
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to
On Thu, Nov 29, 2012 at 11:58 AM, Claudio Freire wrote:
> On Thu, Nov 29, 2012 at 3:32 PM, Jeff Davis wrote:
>>
>> I tried a quick test with 2M tuples and 3 indexes over int8, numeric,
>> and text (generated data). There was also an unindexed bytea column.
>> Using my laptop, a full update of the
Den 11/12/2012 kl. 18.25 skrev Jeff Janes :
> On Tue, Dec 11, 2012 at 2:04 AM, Niels Kristian Schjødt
> wrote:
>> Den 11/12/2012 kl. 00.58 skrev Jeff Janes :
>>
>>>
>>> The fact that there is much more writing than reading tells me that
>>> most of your indexes are in RAM. The amount of index
On Tue, Dec 11, 2012 at 8:25 PM, Huan Ruan wrote:
> Hello All
>
> While investigating switching to Postgres, we come across a query plan that
> uses hash join and is a lot slower than a nested loop join.
>
> I don't understand why the optimiser chooses the hash join in favor of the
> nested loop.
Hi,
Anybody knows a JDBC or a multiplatform code that let read the delete rows of a
table without writing of a table file?
Anybody knows how to create a table using a table file?
thanks
Well, In fact I do (as you can see from my configuration). I have a similar
server running with hot standby replication - and it runs two 3T HDD in a RAID1
array.
So - is it still very bad if I choose to put four intel 520 disks in a RAID10
array on the other production server?
Den 12/12/2012
17 matches
Mail list logo
