It is forward only in the ODBC driver.
"Neil Conway" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Fri, 2003-09-05 at 14:18, Relaxin wrote:
> > Expect that the Declare/Fetch only creates a forwardonly cursor, you can
go
> > backwards thru the result set.
>
> No, DECLARE can crea
<[EMAIL PROTECTED]> writes:
> i'm having _serious_ issues of postgres hogging up the CPU over time. A graph
> showing this can be seen at http://andri.estpak.ee/cpu0.png .
You really haven't shown us anything that would explain that graph ...
repeated UPDATEs will slow down a little until you vacu
Hi,
i'm having _serious_ issues of postgres hogging up the CPU over time. A graph
showing this can be seen at http://andri.estpak.ee/cpu0.png .
The database is running on Redhat 9 (stock 2.4.20-8 kernel), on a reiserfs
partition (~8% usage - no problem there), and this problem has been with
Postg
Neil Conway <[EMAIL PROTECTED]> writes:
> On Fri, 2003-09-05 at 06:07, Richard Huxton wrote:
>> You should find plenty of discussion of why in the archives, but the short
>> reason is that PG's type structure is quite flexible which means it can't
>> afford to make too many assumptions.
> Well,
On Fri, 2003-09-05 at 14:18, Relaxin wrote:
> Expect that the Declare/Fetch only creates a forwardonly cursor, you can go
> backwards thru the result set.
No, DECLARE can create scrollable cursors, read the ref page again. This
functionality is much improved in PostgreSQL 7.4, though.
-Neil
--
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We do have:
> #geqo_random_seed = -1 # -1 = use variable seed
> that lets you force a specific random seed for testing purposes. I
> wonder if that could be extended to control VACUUM radomization too.
> Right now, it just controls GEQO
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > We do have:
> > #geqo_random_seed = -1 # -1 = use variable seed
>
> > that lets you force a specific random seed for testing purposes. I
> > wonder if that could be extended to control VACUUM radomization too.
> > Right
Mary Edie Meredith wrote:
> I certainly don't claim that it is appropriate to force customers into a
> full analysis, particularly if random sampling versus a full scan of the
> data reveals little to no performance differences in the plans. Being
> able to sample accurately is _very nice for larg
Expect that the Declare/Fetch only creates a forwardonly cursor, you can go
backwards thru the result set.
""Patrick Hatcher"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Relaxin,
> I can't remember during this thread if you said you were using ODBC or
not.
> If you are, then y
On Fri, 2003-09-05 at 06:07, Richard Huxton wrote:
> PG's parser will assume an explicit number is an int4 - if you need an int8
> etc you'll need to cast it, yes.
Or enclose the integer literal in single quotes.
> You should find plenty of discussion of why in the archives, but the short
> rea
On Friday 05 September 2003 19:20, Neil Conway wrote:
> On Fri, 2003-09-05 at 06:07, Richard Huxton wrote:
> > PG's parser will assume an explicit number is an int4 - if you need an
> > int8 etc you'll need to cast it, yes.
>
> Or enclose the integer literal in single quotes.
>
> > You should find
I certainly don't claim that it is appropriate to force customers into a
full analysis, particularly if random sampling versus a full scan of the
data reveals little to no performance differences in the plans. Being
able to sample accurately is _very nice for large tables.
For our testing purpose
Mary Edie Meredith <[EMAIL PROTECTED]> writes:
> For our testing purposes, however, consistent results are extremely
> important. We have observed that small difference in one plan for one of
> 22 queries can cause a difference in the DBT-3 results. If this
> happens, a small change in performance
On Friday 05 September 2003 16:36, Rasmus Aveskogh wrote:
> Richard,
>
> Thanks a lot! You were right - the query parser "misunderstood"
> now() - '1 day'::interval and only used one of the indexes (as I already
> noticed).
>
> Actually all I had to do was to cast the result like this:
>
> (now() -
On Fri, 2003-09-05 at 09:39, Jonathan Bartlett wrote:
> > I think I have found out why.. I have a where clause on a ID field but it
> > seems like I need to cast this integer to the same integer as the field is
> > defined in the table, else it will do a tablescan.
>
> Yes, this is correct
>
> >
Richard,
Thanks a lot! You were right - the query parser "misunderstood"
now() - '1 day'::interval and only used one of the indexes (as I already
noticed).
Actually all I had to do was to cast the result like this:
(now() - '1 day'::interval)::date
75s is not between 10ms and 200ms.
Thanks ag
Relaxin,
I can't remember during this thread if you said you were using ODBC or not.
If you are, then your problem is with the ODBC driver. You will need to
check the Declare/Fetch box or you will definitely bring back the entire
recordset. For small a small recordset this is not a problem, but
> I think I have found out why.. I have a where clause on a ID field but it
> seems like I need to cast this integer to the same integer as the field is
> defined in the table, else it will do a tablescan.
Yes, this is correct
> Is this assumtion correct? And if it is, do I then need to change al
On Fri, 2003-09-05 at 12:07, Richard Huxton wrote:
> On Friday 05 September 2003 09:47, Bjorn T Johansen wrote:
> > I think I have found out why.. I have a where clause on a ID field but it
> > seems like I need to cast this integer to the same integer as the field is
> > defined in the table, else
On Friday 05 September 2003 09:47, Bjorn T Johansen wrote:
> I think I have found out why.. I have a where clause on a ID field but it
> seems like I need to cast this integer to the same integer as the field is
> defined in the table, else it will do a tablescan.
>
> Is this assumtion correct? And
I think I have found out why.. I have a where clause on a ID field but it
seems like I need to cast this integer to the same integer as the field is
defined in the table, else it will do a tablescan.
Is this assumtion correct? And if it is, do I then need to change all my
sql's to cast the where c
On Thursday 04 September 2003 23:53, Rasmus Aveskogh wrote:
> Hi,
>
> I have a table that looks like this:
>
> DATA ID TIME
>
> |--||--|
>
> The table holds app. 14M rows now and grows by app. 350k rows a day.
>
> The ID-column holds about 1500 unique values (integer).
> The TIME-
22 matches
Mail list logo
