Through googling, i found that Normal Disk has external data transfer rate of
around 40MBps,
^^
Does this includes, seek and rotational latency ?
where as Main Memory has Data transfer rate
Defaulat values of various parameters in PostgreSQL:
#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)
On Mon, Dec 12, 2005 at 06:39:42PM +0530, Anjan Kumar. A. wrote:
Through googling, i found that Normal Disk has external data transfer rate
of around 40MBps,
where as Main Memory has Data transfer rate ranging from 1.6GBps to 2.8GBps.
I think 40MB/s is a burst speed. You should do some
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
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
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;
Josh Berkus josh@agliodbs.com 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
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
Hi,
I'm very new to this list -- I've been using and advocating PostgreSQL for
no less than 4 or 5 years now, and have participated in some of the other
mailing lists, but never on this one.
My question is (short version): how would one go about adding a new
(built-in) function to PostgreSQL?
Ühel kenal päeval, P, 2005-12-11 kell 17:55, kirjutas Carlos Moreno:
Hi,
I'm very new to this list -- I've been using and advocating PostgreSQL for
no less than 4 or 5 years now, and have participated in some of the other
mailing lists, but never on this one.
My question is (short
Actually, there is probably comparatively little to gain from making it
a builtin. And SHA1 is already there in the pgcrypto contrib module.
Presumably if we wanted a builtin we would start from that code base.
cheers
andrew
Carlos Moreno wrote:
Hi,
I'm very new to this list -- I've
Am Sonntag, den 11.12.2005, 17:55 -0500 schrieb Carlos Moreno:
...
I'm interested in adding additional hash functions -- PG supports, as part
of the built-in SQL functions, MD5 hashing. So, for instance, I can simply
type, at a psql console, the following:
select md5('abc');
My feature
12 matches
Mail list logo