Nabble - PostgreSQL - benchmarks

Re: Benchmarking tools for the Postgres, EDB and Oracle Database

2007-04-27T09:40:19Z

On Apr 12, 2007, at 2:04 PM, Ranjan Sahoo wrote:
> I am working on a project for testing the performance of Oracle,
> EDB, and postgres and looking for a OLTP benchmarking tool which
> can do the benchmarking on all these databases. Can anyone please
> help me on this?

Take a look at http://sourceforge.net/projects/benchmarksql
--
Jim Nasby jim@...
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Benchmarking tools for the Postgres, EDB and Oracle Database

2007-04-12T07:04:35Z

Hi AllJ

I am working on a project for testing the performance of Oracle, EDB, and postgres and looking for a OLTP benchmarking tool which can do the benchmarking on all these databases. Can anyone please help me on this?

Thanks in advance to all for you kind co-operation.

Regards

Ranjan

Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.

Re: testing

2006-09-06T06:41:55Z

....

On 9/6/06, Rafaqat Ali <smoken0@...> wrote:

Please ignore this email.
This is just to test is it working.

testing

2006-09-06T01:19:24Z

Please ignore this email.
This is just to test is it working.

Re: postgis

2006-07-26T09:59:33Z

Please fix your caps-lock.

If you look on the PostGIS site, you'll find that they have their own
mailing lists. You should ask for help there.

On Jul 25, 2006, at 3:26 PM, ASTRO wrote:

> HI
> I APOLOGISE FOR MY BAD ENGLISH
> I USE POSTGRESQL WHIT POSTGIS
> I HAVE A PROBLEM WITH THE GROMETRY COLLECTION DATA TYPE
> I WOULD ASK IF THERE AREN'T A FUNCTION TO CONVERT A GEOMETRY
> COLLECTION (AS MULTIPOINT FOR EXEMPLE) IN GEOMETRY TYPE
> I TRY TO USE THE FUNCTION AsText BUT IT'S NOT POSSIBLE TO SEE THE
> POINT OF THE COLLECTION
> THANKS
> ASTRO
>
>
> PS:I TRY AGAIN TO FIND A SOLUTION AND IF I'LL FIND IT I'LL SEND YOU
> A MAIL WITH THE SOLUTION

--
Jim C. Nasby, Sr. Engineering Consultant jnasby@...
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

postgis

2006-07-25T14:26:01Z

HI
I APOLOGISE FOR MY BAD ENGLISH
I USE POSTGRESQL WHIT POSTGIS
I HAVE A PROBLEM WITH THE GROMETRY COLLECTION DATA TYPE
I WOULD ASK IF THERE AREN'T A FUNCTION TO CONVERT A GEOMETRY COLLECTION (AS MULTIPOINT FOR EXEMPLE) IN GEOMETRY TYPE
I TRY TO USE THE FUNCTION AsText BUT IT'S NOT POSSIBLE TO SEE THE POINT OF THE COLLECTION
THANKS
ASTRO

PS:I TRY AGAIN TO FIND A SOLUTION AND IF I'LL FIND IT I'LL SEND YOU A MAIL WITH THE SOLUTION

PROBLEMAS CON POSTGRES EN MAQUINAS MULTIPROCESADORES

2006-05-24T10:03:28Z

lists

Saludos,

Resulta que el tiempo de ejecución obtenido en una maquina HP DL380 con
2 procesadores Xeon de 3.6 Gh y 4G de memoria con el siguiente comando
"cat nombrearchivo.gz | gunzip | psql nombrebd -f -" es de 4 horas...

este mismo Proceso en una maquina de DL580 con 4 procesadores de 3.0 Gh
y 8G de memoria su tiempo de ejecución es de 5 horas y media.

Las anteriores pruebas se ejecutaron utilizando POSTGRES 8.03 en un
sistema operativo REDHAT 4.2 de 64.

La inquietud es si POSTGRES a presentado problemas en maquinas de 64b
con múltiples procesadores.. lo decimos con base en los tiempos de
ejecución expuestos anteriormente..

Otra prueba realizada fue en la maquina de 64b se realizo el mismo
proceso pero no utilizando SMP y el tiempo de respuesta fue de 3horas y
media (pareciera que postgres tiene problemas con varios procesadore)

Existe alguna solución? o algún ajuste posible?, alguna recomendación?

--
__________________________
Juan Jimmy Salazar Ramirez
Ingeniero Informatico
Analista Programador
Solati Ltda.
Medellin - Colombia
Tel. 268-75-51

>>>>end

Saludos,

Resulta que el tiempo de ejecución obtenido en una maquina HP DL380 con
2 procesadores Xeon de 3.6 Gh y 4G de memoria con el siguiente comando
"cat nombrearchivo.gz | gunzip | psql nombrebd -f -" es de 4 horas...

este mismo Proceso en una maquina de DL580 con 4 procesadores de 3.0 Gh
y 8G de memoria su tiempo de ejecución es de 5 horas y media.

Las anteriores pruebas se ejecutaron utilizando POSTGRES 8.03 en un
sistema operativo REDHAT 4.2 de 64.

La inquietud es si POSTGRES a presentado problemas en maquinas de 64b
con múltiples procesadores.. lo decimos con base en los tiempos de
ejecución expuestos anteriormente..

Otra prueba realizada fue en la maquina de 64b se realizo el mismo
proceso pero no utilizando SMP y el tiempo de respuesta fue de 3horas y
media (pareciera que postgres tiene problemas con varios procesadore)

Existe alguna solución? o algún ajuste posible?, alguna recomendación?

--
__________________________
Juan Jimmy Salazar Ramirez
Ingeniero Informatico
Analista Programador
Solati Ltda.
Medellin - Colombia
Tel. 268-75-51

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Re: [DOCS] [HACKERS] Please Help: PostgreSQL Query Optimizer

2005-12-12T22:46:51Z

Anjan,

> But, in PostgreSQL all costs are scaled relative to a page fetch. If we
> make both sequential_page_fetch_cost and random_page_cost to "1", then we
> need to increase the various cpu_* paramters by multiplying the default
> values with appropriate Scaling Factor. Now, we need to determine this
> Scaling Factor.

I see, so you're saying that because the real cost of a page fetch has
decreased, the CPU_* costs should increase proportionally because relative to
the real costs of a page fetch they should be higher? That makes a sort of
sense.

The problem that you're going to run into is that currently we have no
particularly reason to believe that the various cpu_* costs are more than
very approximately correct as rules of thumb. So I think you'd be a lot
better off trying to come up with some means of computing the real cpu costs
of each operation, rather than trying to calculate a multiple of numbers
which may be wrong in the first place.

I know that someone on this list was working on a tool to digest EXPLAIN
ANALYZE results and run statistics on them. Can't remember who, though.

Also, I'm still curious on how you're handling shared_mem, work_mem and
maintenance_mem. You didn't answer last time.

--
Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Re: [DOCS] [HACKERS] Please Help: PostgreSQL Query Optimizer

2005-12-11T14:06:01Z

Since sequential access is not significantly faster than random access in a MMDB, random_page_cost will be approximately same as sequential page fetch cost.

As every thing is present in Main Memory, we need to give approximately same cost to read/write to Main Memory and CPU Related operations.

But, in PostgreSQL all costs are scaled relative to a page fetch. If we make both sequential_page_fetch_cost and random_page_cost to "1", then we need to increase the various cpu_* paramters by multiplying the default values with appropriate Scaling Factor. Now, we need to determine this Scaling Factor.

Still, i want to confirm whether this approach is the correct one.

On Sun, 11 Dec 2005, Josh Berkus wrote:

> Anjan,
>
>> In our case we are reading pages from Main Memory File System, but not from
>> Disk. Will it be sufficient, if we change the default values of above
>> paramters in "src/include/optimizer/cost.h and
>> src/backend/utils/misc/postgresql.conf.sample" as follows:
>>
>> random_page_cost = 4;
>
> This should be dramatically lowered. It's supposed to represent the ratio of
> seek-fetches to seq scans on disk. Since there's no disk, it should be a
> flat 1.0. However, we are aware that there are flaws in our calculations
> involving random_page_cost, such that the actual number for a system where
> there is no disk cost would be lower than 1.0. Your research will hopefully
> help us find these flaws.
>
>> cpu_tuple_cost = 2;
>> cpu_index_tuple_cost = 0.2;
>> cpu_operator_cost = 0.05;
>
> I don't see why you're increasing the various cpu_* costs. CPU costs would be
> unaffected by the database being in memory. In general, I lower these by a
> divisor based on the cpu speed; for example, on a dual-opteron system I lower
> the defaults by /6. However, that's completely unrelated to using an MMDB.
>
> So, other than random_page_cost, I don't know of other existing GUCs that
> would be directly related to using a disk/not using a disk. How are you
> handling shared memory and work memory?
>
> I look forward to hearing more about your test!
>
>

--
Regards.

Anjan Kumar A.
MTech2, Comp Sci.,
www.cse.iitb.ac.in/~anjankumar
______________________________________________________________
Do not handicap your children by making their lives easy.
-- Robert Heinlein

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Re: [DOCS] [HACKERS] Please Help: PostgreSQL Query Optimizer

2005-12-11T12:41:36Z

Josh Berkus <josh@...> writes:
> I don't see why you're increasing the various cpu_* costs.

You missed the point Josh --- these numbers are relative to the cost of
a page fetch, so if page fetch is measured in microseconds instead of
milliseconds, then you *do* want to bump the CPU costs up.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Re: [DOCS] [HACKERS] Please Help: PostgreSQL Query Optimizer

2005-12-11T11:25:46Z

Anjan,

> In our case we are reading pages from Main Memory File System, but not from
> Disk. Will it be sufficient, if we change the default values of above
> paramters in "src/include/optimizer/cost.h and
> src/backend/utils/misc/postgresql.conf.sample" as follows:
>
> random_page_cost = 4;

This should be dramatically lowered. It's supposed to represent the ratio of
seek-fetches to seq scans on disk. Since there's no disk, it should be a
flat 1.0. However, we are aware that there are flaws in our calculations
involving random_page_cost, such that the actual number for a system where
there is no disk cost would be lower than 1.0. Your research will hopefully
help us find these flaws.

> cpu_tuple_cost = 2;
> cpu_index_tuple_cost = 0.2;
> cpu_operator_cost = 0.05;

I don't see why you're increasing the various cpu_* costs. CPU costs would be
unaffected by the database being in memory. In general, I lower these by a
divisor based on the cpu speed; for example, on a dual-opteron system I lower
the defaults by /6. However, that's completely unrelated to using an MMDB.

So, other than random_page_cost, I don't know of other existing GUCs that
would be directly related to using a disk/not using a disk. How are you
handling shared memory and work memory?

I look forward to hearing more about your test!

--
Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

[pgsql-chat] Please Help: PostgreSQL Query Optimizer

2005-12-11T02:45:26Z

I'm working on a project, whose implementation deals with PostgreSQL. A brief description of the project is given below.

Project Description:
--------------------
In Main Memory DataBase(MMDB) entire database on the disk is loaded on to the main memory during initial startup of the system. There after all the references are made to database on the main memory. When the system is going to shutdown, we will write back the database on the main memory to disk. Here, for the sake of recovery we are writing log records on to the disk during the transaction execution.

We want to implement MMDB by modifying PostgreSQL. We implemented our own Main Memory File System to store the primary copy of the database in main memory, and Modified the PostgreSQL to access the data in the Main Memory File System.

Now, in our implementation Disk access is completely avoided during normal transaction execution. So, we need to modify the Query Optimizer of PostgreSQL so that it wont consider disk related costs during calculation of Query Costs. Query Optimizer should try to minimize the Processing Cost. The criteria for cost can be taken as the number of tuples that have to read/write from main memory, number of comparisons, etc.

Can any one tell me the modifications needs to be incorporated to PostgreSQL, so that it considers only Processing Costs during optimization of the Query.

In PostgreSQL, Path costs are measured in units of disk accesses. One sequential page fetch has cost 1. I think, in PostgreSQL following paramters are used in calculating the cost of the Query Path :

#random_page_cost = 4 # units are one sequential page fetch cost
#cpu_tuple_cost = 0.01 # (same)
#cpu_index_tuple_cost = 0.001 # (same)
#cpu_operator_cost = 0.0025 # (same)
#effective_cache_size = 1000 # typically 8KB each

In our case we are reading pages from Main Memory File System, but not from Disk. Will it be sufficient, if we change the default values of above paramters in "src/include/optimizer/cost.h and src/backend/utils/misc/postgresql.conf.sample" as follows:

random_page_cost = 4;
cpu_tuple_cost = 2;
cpu_index_tuple_cost = 0.2;
cpu_operator_cost = 0.05;

Please help us in this regard. I request all of you to give comments/suggestions on this. Waiting for your kind help.

--
Thanks.

Anjan Kumar A.
MTech2, Comp Sci.,
www.cse.iitb.ac.in/~anjankumar
______________________________________________________________
May's Law:
The quality of correlation is inversly proportional to the density
of control. (The fewer the data points, the smoother the curves.)

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Re: Error when try installing pgbench ?

2005-05-21T01:42:00Z

you need to use gmake perhaps?

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@...