On Fri, Jan 27, 2012 at 06:31, sridhar bamandlapally
wrote:
> --
> | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
> --
> | 0
27.01.12 11:06, Marti Raudsepp написав(ла):
On Fri, Jan 27, 2012 at 06:31, sridhar bamandlapally
wrote:
--
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
On 27 Leden 2012, 10:06, Marti Raudsepp wrote:
> On Fri, Jan 27, 2012 at 06:31, sridhar bamandlapally
> wrote:
>> --
>> | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
>> |
>> -
sridhar bamandlapally, 27.01.2012 05:31:
SQL> explain plan for select * from hr.emp ;
Explained.
PLAN
--
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-
For security reasons, I cannot put real-time senario into loop,
the one which I gave is an example, if I have solution for this then
same will be applied for real-time senario
We have implemented PARALLEL technology into our database and same
expecting after migration to PostgreSQL,
The real-tim
On 27 Leden 2012, 13:16, sridhar bamandlapally wrote:
> For security reasons, I cannot put real-time senario into loop,
The point of Marti's comment was that the estimates (as presented by
EXPLAIN PLAN FOR in Oracle) are inherently imprecise. Don't trust what
Oracle is telling you about the expect
Hi,
We are having an embedded system with a freescale m68k architecture based
micro-controller, 256MB RAM running a customized version of Slackware 12 linux.
It's a relatively modest Hardware.
We have installed postgres 9.1 as our database engine. While testing, we found
that the Postgres operat
>> the one which I gave is an example, if I have solution for this then
>> same will be applied for real-time senario
>
> There's no way to execute a single query in a parallel manner and it won't
> be available anytime soon.
>
> This is not an issue unless you have a CPU bound query and you have u
On Thu, Jan 26, 2012 at 6:09 PM, Carlo Stonebanks
wrote:
> Assuming there was some sort of cost to pl/pgsql, I rewrote a bunch of
> stored functions s in straight SQL. Each stored proc was calling the next,
> so to get the full effect I had to track down all the pl/pgsql stored
> functions and con
On 27.01.2012 15:34, Jayashankar K B wrote:
Hi,
We are having an embedded system with a freescale m68k architecture based
micro-controller, 256MB RAM running a customized version of Slackware 12 linux.
It's a relatively modest Hardware.
Fascinating!
We have installed postgres 9.1 as our dat
On 1/27/2012 10:47 AM, Heikki Linnakangas wrote:
On 27.01.2012 15:34, Jayashankar K B wrote:
Hi,
We are having an embedded system with a freescale m68k architecture
based micro-controller, 256MB RAM running a customized version of
Slackware 12 linux.
It's a relatively modest Hardware.
Fascina
Let's say I have a 7GB table with 3-4 indices for a total of 10-12GB.
Furthermore, let's say I have a machine with sufficient memory for me
to set the work_mem and maintenance_work_mem to 20GB (just for this
session).
When I issue a CLUSTER using one of the indices, I see PostgreSQL (by
way of str
On 27.01.2012 19:43, Jon Nelson wrote:
Let's say I have a 7GB table with 3-4 indices for a total of 10-12GB.
Furthermore, let's say I have a machine with sufficient memory for me
to set the work_mem and maintenance_work_mem to 20GB (just for this
session).
When I issue a CLUSTER using one of the
Hi Heikki Linnakangas: We are using series of Insert statements to insert the
records into database.
Sending data in binary is not an option as the module that writes into DB has
been finalized.
We do not have control over that.
Hi Andy: As of now, there are no triggers in the table.
Please let
Yes, I did test it - i.e. I ran the functions on their own as I had always
noticed a minor difference between EXPLAIN ANALYZE results and direct query
calls.
Interesting, so sql functions DON'T cache plans? Will plan-caching be of any
benefit to SQL that makes no reference to any tables? The SQL
You can use PREPARE... EXECUTE to "cache" the plan (as well as
parsing). However, I find it unlikely this will would explain the
loss in performance you experienced.
Deron
On Fri, Jan 27, 2012 at 11:36 AM, Carlo Stonebanks
wrote:
> Yes, I did test it - i.e. I ran the functions on their own a
On 27.01.2012 20:30, Jayashankar K B wrote:
Hi Heikki Linnakangas: We are using series of Insert statements to insert the
records into database.
Sending data in binary is not an option as the module that writes into DB has
been finalized.
We do not have control over that.
That certainly limit
Was I even right in thinking I would gain any performance by converting to
SQL?
-Original Message-
From: Deron [mailto:fecas...@gmail.com]
Sent: January 27, 2012 2:29 PM
To: Carlo Stonebanks
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] pl/pgsql functions outperforming sql o
On Jan 27, 2012, at 2:59 PM, Carlo Stonebanks wrote:
> Was I even right in thinking I would gain any performance by converting to
> SQL?
As always, it depends. I converted an immutable pl/pgsql function to an SQL
function and the body of the function barely changed. However, I experienced an
o
On Fri, Jan 27, 2012 at 4:56 PM, Heikki Linnakangas
wrote:
> I don't think there's anything particular in postgres that would make it a
> poor choice on a small system, as far as CPU usage is concerned anyway. But
> inserting rows in a database is certainly slower than, say, writing them
> into a
On Fri, Jan 27, 2012 at 12:05 PM, Heikki Linnakangas
wrote:
> On 27.01.2012 19:43, Jon Nelson wrote:
>>
>> Let's say I have a 7GB table with 3-4 indices for a total of 10-12GB.
>> Furthermore, let's say I have a machine with sufficient memory for me
>> to set the work_mem and maintenance_work_mem
On Fri, Jan 27, 2012 at 7:34 PM, Jon Nelson wrote:
> On Fri, Jan 27, 2012 at 12:05 PM, Heikki Linnakangas
> wrote:
>> On 27.01.2012 19:43, Jon Nelson wrote:
>>>
>>> Let's say I have a 7GB table with 3-4 indices for a total of 10-12GB.
>>> Furthermore, let's say I have a machine with sufficient me
On Fri, Jan 27, 2012 at 6:34 AM, Jayashankar K B
wrote:
> Hi,
>
> We are having an embedded system with a freescale m68k architecture based
> micro-controller, 256MB RAM running a customized version of Slackware 12
> linux.
>
> It’s a relatively modest Hardware.
>
> We have installed postgres 9.1
2012/1/27 Carlo Stonebanks :
> Yes, I did test it - i.e. I ran the functions on their own as I had always
> noticed a minor difference between EXPLAIN ANALYZE results and direct query
> calls.
>
> Interesting, so sql functions DON'T cache plans? Will plan-caching be of any
> benefit to SQL that ma
24 matches
Mail list logo
