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 "fe
Bruce Momjian writes:
> Christopher Kings-Lynne wrote:
>> Is there any way to force COPY to accept that there will be lines of
>> different length in a data file?
> I suppose we could have a TRAILINGNULL flag to COPY but because few ask
> for this feature, it hardly seems worth it.
There is no
Christopher Kings-Lynne wrote:
> Hi,
>
> Is there any way to force COPY to accept that there will be lines of
> different length in a data file?
>
> I have a rather large file I'm trying to import. It's in CSV format,
> however, they leave off trailing empty columns on most lines.
>
> Any way
Hi,
Is there any way to force COPY to accept that there will be lines of
different length in a data file?
I have a rather large file I'm trying to import. It's in CSV format,
however, they leave off trailing empty columns on most lines.
Any way to do this? Should it be supported by CSV mo
Hannu Krosing wrote:
Ü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
On 8.1.1 compiled and installed on Mac OS X 10.4.3 using only the
provided libraries, I'm receiving the following error when exiting psql:
could not save history to file "/{homedir}/.psql_history":
Invalid argument
I see that Tom Lane tracked down the problem back on August 28th:
Hannu Krosing wrote:
Ask your question as a separate post, not as an answer t another
thread :)
Also, if you post to a mailing list, you should have the courtesy to
arrange it so your spam filter does not reject replies.
cheers
andrew
---(end of broadcast)--
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 bee
Ü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 v
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?
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 operation
I wrote:
> So it seems it's time to start thinking about how to reduce contention
> for the LockMgrLock.
> ...
> The best idea I've come up with after a bit of thought is to replace the
> shared lock table with N independent tables representing partitions of the
> lock space.
I've committed change
Josh Berkus 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.
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
Ühel kenal päeval, L, 2005-12-10 kell 21:07, kirjutas Tom Lane:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > How do you plan to determine "any rows not already present in the index"
> > without explicitly remembering the start and end snapshots of existing
> > CREATE INDEX (SNAP1 and SNAP2 in my
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Regarding CREATEROLE, I wonder why is that a role with that privilege is
> able to create other roles containing any privileges (except
> superuserness), and not just the privileges the creating role has.
The point of CREATEROLE was to allow a role to d
[ trimming cc list to something sane ]
"Anjan Kumar. A." <[EMAIL PROTECTED]> writes:
> 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.
On Sat, 2005-12-10 at 21:07 -0500, Tom Lane wrote:
> In any case the design idea here
> seems to be "we don't care how long REINDEX takes as long as it's not
> blocking anyone".
All sounds great so far. I'd like this as an option for CREATE INDEX
also.
Best Regards, Simon Riggs
--
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 sys
19 matches
Mail list logo
