Tom Lane escreveu:
Thomas Kellerer <[EMAIL PROTECTED]> writes:
Is there anything I can do, to convince PG to return the first row more
quickly?
Are you now looking for the LIMIT ?
SELECT * FROM table LIMIT 1;
and when when you wnat the rest of it:
SELECT * FROM table OFFSET 1;
.
What I would like to calculate is (AValue2-AValue1) for a given Num
(here num1).
In this case, I would have to calculate
60-50 for Num 10
and
43-55, 62-43 for Num 25.
Do you have any idea if it can be done simply with a request...
I thank you
Regards.
Alain Reymond
gs go sour...
Can someone explain it please?
thanks,
Alain
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
ng postgre 7.4.1)
The 3rd order by is not indexed, but it operates in a memory table of no
more than 200 so it is fast too.
Please comment on this. I tested and it worked but I really new to sql
and I feel insecure...
Thanks,
Alain
[how to solve the get next 100 records problem]
BUT, I th
tremely fast with 600 records and it looks like
the few redundant or empty queries (but very fast) will not be a problem.
What is your opinion about this (apart that it is a bit complex :) ??
Alain
---(end of broadcast)---
TIP 6: Have you searched
one for each phone number).
I tried using both the name and the primary key (with a combined index),
to get faster to the record I want, but I was not sucessfull in building
a where clause.
I would appreciate any help, in fact this is my primary reason for
joining this list ;-)
Al
o what you want. I think.
The problem is probably speed. I have done a lot of tests, and when
OFFSET gets to a few thousands on a multimega-recs database, it gets
very very slow... Is there any other to work around that?
Alain
---(end of broadcast)---
for your suggestions.
Regards.
Alain Reymond
CEIA
Bd Saint-Michel 119
1040 Bruxelles
Tel: +32 2 736 04 58
Fax: +32 2 736 58 02
[EMAIL PROTECTED]
PGP key sur http://pgpkeys.mit.edu:11371
---(end of broadcast)---
TIP 8: explain analyze is your
(#assessment_nr, labtest_nr) for only one integer and one real per row. And I
can have up to 1.500.000 rows per year with at least 10 years on line... It means big
indexes.
Regards.
Alain
> I would go for the second one. I think the size of the table is not a
> problem. You will have j
ults and 2
for identification. I would like to store 10 years online, so 15.000.000 rows. What
about the size of index ?
Any advise ? I thank you in advance.
Alain Reymond
(I hope that it is clear enough with my bad English).
---(end of broadcast)-
Thanks that worked, but why does that happen or maybe you could point to the proper
thread so I read up on it.
Alain Lavigne - Data Administrator - ZAQ Interactive Solutions E-Mail:
[EMAIL PROTECTED
..2264.16 rows=1 width=8)
EXPLAIN
I don't understand why it's not using the defined index, even after performing VACUUM
FULL ANALYZE on the table.
I tried disabling seqscan but that didn't change anything.
I'm open to suggestions anyone
Thanks!
---
I'm trying to extract references (relationships) between tables for the
purpose of reverse/forward engineer from a modeling tool called
PowerDesigner.
Here is the sql:
select u.usename,
p.relname,
v.usename,
c.relname,
t.tgconstrname,
dumpref(t.tgargs, 4), **
casts >>
What am I doing wrong ??
Alain Lavigne - Data Administrator - ZAQ.iTv - E-Mail: [EMAIL PROTECTED]
297 St-Paul, West - Montreal, Quebec, Canada - H2Y 2A5
Phone: 514-282-7073 ext: 371
Fax: 514-282-8011
; ),the pentium gcc group in this
case used gcc 2.95.2,applied their pentium patches and released the thing
as pgcc 2.95.3,that's the stock compiled used by mandrake.
Alain Toussaint
15 matches
Mail list logo
