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 DEFAULT
Dnia 2004-01-26 15:12, Użytkownik 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
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.
But now that I'm looking a
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.
But
[EMAIL PROTECTED] ("Joshua D. Drake") writes:
>>Well, I'd point to one major factor with RHAT; they employ Stephen
>>Tweedie, creator of ext3, and have been paying him to work on it for
>>some time now. If they _didn't_ promote use of ext3, they would be
>>very much vulnerable to the "won't eat th
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.
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
> WH
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 vi
Tom Lane wrote:
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
Thanks Tom! You're a life-saver.
On Fri, 2004-01-23 at 17:08, Tom Lane wrote:
> Orion Henry <[EMAIL PROTECTED]> writes:
> > The queries usually are in the form of, where "user_id = something and
> > event_time between something and something".
>
> > Half of my queries index off of the user_id an
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
JBo
Drew,
Just a guess because I don't know PostGres that well, but it could be the
SQL parse time and once the statement is parsed, it may be pinned in parse
cache for subsequent calls.
Regards,
Brad Gawne
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of PC
12 matches
Mail list logo
