Hi all,
First of all thanks to Josh and Richard for their replies. What I have
done to test
their indications is the following. I have created a new table identical to
STATISTICS,
and an index over the TIMESTAMP_IN field.
CREATE TABLE STATISTICS2
(
STATISTIC_IDNUMERIC(10) NOT NULL
Dnia 2004-01-26 15:12, Uytkownik Arnau napisa:
Hi all,
First of all thanks to Josh and Richard for their replies. What I have
done to test
their indications is the following. I have created a new table identical to
STATISTICS,
and an index over the TIMESTAMP_IN field.
CREATE TABLE STATISTICS2
(
Bill Moran wrote:
I have an application that I'm porting from MSSQL to PostgreSQL. Part
of this
application consists of hundreds of stored procedures that I need to
convert
to Postgres functions ... or views?
At first I was going to just convert all MSSQL procedures to Postgres
functions.
Christopher Browne [EMAIL PROTECTED] writes:
Ah, but there is a bit of a 'problem' nonetheless; XFS is not
'officially supported' as part of the Linux kernel until version 2.6,
which is still pretty bleeding edge. Until 2.6 solidifies a bit
more (aside: based on experiences with 2.6.0,
Bill Moran [EMAIL PROTECTED] writes:
At first I was going to just convert all MSSQL procedures to Postgres functions.
But now that I'm looking at it, a lot of them may be candidates for views. A
lot of them take on the format of:
SELECT a.cola, b.colb, c.colc
FROM a JOIN b JOIN c
WHERE
Bill,
SELECT a.cola, b.colb, c.colc
FROM a JOIN b JOIN c
WHERE a.prikey=$1
If your views are simple, PostgreSQL will be able to push down any filter
criteria into the view itself. For example,
CREATE view_a AS
SELECT a.cola, b.colb, c.colc
FROM a JOIN b JOIN c;
SELECT * FROM view_a
I'm trying to track down some performance issues where time (in
milliseconds) is critical. One thing that I've noticed is that it
seems like the first insert takes an inordinate amount of time.
Inserts after the first one are acceptable. My production environment
is like this:
Solaris 9
