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
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
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 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 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 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
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 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
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
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
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
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
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 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
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 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
>> 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
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
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
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
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 |
-
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
>> |
>> -
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 Fri, Jan 27, 2012 at 06:31, sridhar bamandlapally
wrote:
> --
> | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
> --
> | 0
24 matches
Mail list logo
