Well, I re-wrote the algorithm in Perl. However, it did not solve the speed
issue. Running time now is a whopping 240+ ms instead of the 31.8ms I was
getting before (15.2 of which is sorting). Here is the Perl code on the
sorting. I won't post the pl/pgsql code, because this is far more clear (in
m
On 03/07/10 00:36, Craig James wrote:
> Perl itself is written in C, and some of it's operations are extremely
> fast.
The same is true of PL/PgSQL, though ;-)
The main advantage of PL/Perl is that it doesn't rely on the SPI to do
everything. It's interpreted not compiled, but it has a much fast
On Fri, Jul 2, 2010 at 7:38 AM, MUHAMMAD ASIF wrote:
> Hi,
>
> We are using dbt2 to check performance of postgresql 8.4 on Linux64 machine.
> When we increase "TERMINALS PER WAREHOUSE" TPM value increase rapidly but
> rampup time increase too , dbt2 estimated rampup time calculation do not
> work
Robert Haas wrote:
> On Fri, Jul 2, 2010 at 4:58 PM, Tom Lane wrote:
> > Bruce Momjian writes:
> >> I am surprised there is no documentation update requirement for this.
> >
> > Somebody put something about it in the docs a few days ago, IIRC.
>
> That was me.
>
> http://archives.postgresql.org
On Fri, Jul 2, 2010 at 4:58 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> I am surprised there is no documentation update requirement for this.
>
> Somebody put something about it in the docs a few days ago, IIRC.
That was me.
http://archives.postgresql.org/pgsql-committers/2010-06/msg00144.ph
Bruce Momjian writes:
> I am surprised there is no documentation update requirement for this.
Somebody put something about it in the docs a few days ago, IIRC.
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make change
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I would have liked to get to this for 9.0 but I feel it's a bit late
> >> now.
>
> > What do we want to do about the above issue?
>
> TODO item.
Added to TODO:
Have autoanalyze of parent tables occur when child tables are mod
Dear Deb,
i feel three distinct steps are present
1. CREATE TABLE
2. LOAding of data in tables
3. Creation of indexes
It is still not clear when you are seeing your system becoming unresponsive
to
other application. Is it during loading of data or creation of indexes?
1. can you give any idea a
Dear Criag,
Thanks for thinking about it.I do not understand why u feel OpenVz is weird.
at the most its not very popular. But lets not get into that debate as its
not
the proper forum. From your reply i understand that there is not a easy and
clean way of doing it. Since performance related profi
On Tue, Jun 29, 2010 at 7:59 AM, Sergio Charpinel Jr.
wrote:
> One more question about two specifics query behavior: If I add "AND (ip_dst
> = x.x.x.x)", it uses another plan and take a much more time. In both of
> them, I'm using WHERE clause. Why this behavior?
With either query, the planner is
In postgresql.conf, what are your settings for constraint_exclusion?
There are 3 settings - on, off, or partition.
Mine are set as follows:
constraint_exclusion = on# on, off, or partition
Under 8.4.4 I had it set to partition, but the behavior was not what I
expected so I set
On 7/2/10 6:59 AM, Eliot Gable wrote:
Yes, I have two pl/pgsql functions. They take a prepared set of data
(just the row id of the original results, plus the particular priority
and weight fields) and they return the same set of data with an extra
field called "order" which contains a numerical o
Hi,
My question is regarding ORDER BY / LIMIT query behavior when using
partitioning.
I have a large table (about 100 columns, several million rows) partitioned by a
column called day (which is the date stored as mmdd - say 20100502 for May
2nd 2010 etc.). Say the main table is called FA
On Fri, Jul 2, 2010 at 10:50 AM, Matthew Wakeling wrote:
>> On Fri, Jul 2, 2010 at 12:08 AM, Tom Lane wrote:
>>>
>>> I'm guessing from tea leaves, but the impression I got from Eliot's
>>> description is that he's using plpgsql functions as sort comparators.
>>> It's not surprising that that suck
On Fri, Jul 2, 2010 at 12:08 AM, Tom Lane wrote:
I'm guessing from tea leaves, but the impression I got from Eliot's
description is that he's using plpgsql functions as sort comparators.
It's not surprising that that sucks performance-wise compared to having
the equivalent logic in C/C++ functio
Hi,
We are using dbt2 to check performance of postgresql 8.4 on Linux64 machine.
When we increase "TERMINALS PER WAREHOUSE" TPM value increase rapidly but
rampup time increase too , dbt2 estimated rampup time calculation do not work
properly that’s why it run the test for wrong duration i.e.
Yes, I have two pl/pgsql functions. They take a prepared set of data (just
the row id of the original results, plus the particular priority and weight
fields) and they return the same set of data with an extra field called
"order" which contains a numerical order to apply when sorting the rows. One
On Thu, Jul 1, 2010 at 8:46 PM, Eliot Gable
wrote:
> I have a long stored procedure (over 3,000 lines). Originally, it would take
> about 44ms to run the whole query. After lots and lots of tweaking, Postgres
> now runs the entire thing and gathers my results in just 15.2ms, which is
> very impres
Hello,
I try to make a query run quicker but I don't really know how to give
hints to the planner.
We are using postgresql 8.4.3 64bit on ubuntu 9.10 server. The hardware
is a 10 SAS drive (15k) on a single RAID 10 array with 8Go RAM.
Queries come from J2EE application (OLAP cube), but runnin
19 matches
Mail list logo
