On Mon, 2004-01-05 at 14:57, David Teran wrote:
> ... wow:
>
> executing a batch file with about 4250 selects, including lots of joins
> other things PostgreSQL 7.4 is about 2 times faster than FrontBase
> 3.6.27. OK, we will start to make larger tests but this is quite
> interesting already: w
David Teran <[EMAIL PROTECTED]> writes:
> Much better. So i think i will first read more about this optimization
> stuff and regular maintenance things.
See http://www.postgresql.org/docs/7.4/static/maintenance.html
> Is there any hint where to start to understand more about this
> optimizati
... wow:
executing a batch file with about 4250 selects, including lots of joins
other things PostgreSQL 7.4 is about 2 times faster than FrontBase
3.6.27. OK, we will start to make larger tests but this is quite
interesting already: we did not optimize a lot, just invoked VACUUM
ANALYZE and t
David Teran wrote:
> Index?Scan?using?key_value_meta_data__id_value__fk_index,?key_value_meta
> _data__id_value__fk_index?on?"KEY_VALUE_META_DATA"?t0??(cost=0.00..19.94
> ?rows=14?width=75)?(actual?time=0.112..0.296?rows=25?loops=1)
> ??Index?Cond:?(("ID_VALUE"?=?21094)?OR?("ID_VALUE"?=?21103))
>
Hi Tom,
first of all thanks for your help! I really appreciate your fast
response and if you ever have a question about WebObjects, just drop me
line ;-)
Seq Scan on "KEY_VALUE_META_DATA" t0 (cost=0.00..2671.16 rows=931
width
=1068) (actual time=122.669..172.179 rows=25 loops=1)
Filter:
David Teran <[EMAIL PROTECTED]> writes:
> explain result from second query:
> Seq Scan on "KEY_VALUE_META_DATA" t0 (cost=0.00..2671.16 rows=931 width
> =1068) (actual time=122.669..172.179 rows=25 loops=1)
> Filter: (("ID_VALUE" = 21094) OR ("ID_VALUE" = 21103))
The problem is evidently that
Hi Tom,
David Teran <[EMAIL PROTECTED]> writes:
What we found out now is that a query with a single 'where' works
fine,
the query planer uses the index but when we have 'two' where clauses
it
does not use the index anymore:
EXPLAIN ANALYZE SELECT columns... FROM "KEY_VALUE_META_DATA" t0 WHE
David Teran <[EMAIL PROTECTED]> writes:
> What we found out now is that a query with a single 'where' works fine,
> the query planer uses the index but when we have 'two' where clauses it
> does not use the index anymore:
> EXPLAIN ANALYZE SELECT columns... FROM "KEY_VALUE_META_DATA" t0 WHERE
Hi Tom,
It's worth pointing out that this problem is fixed (at long last) in
CVS tip. Ypu probably shouldn't expend large amounts of effort on
working around a problem that will go away in 7.5.
We have now changed the definition to integer, this will work for some
time. We are currently evaluati
David Teran <[EMAIL PROTECTED]> writes:
> This is my bigger problem: i am using EOF (OR mapping tool) which frees
> me more or less form writing a lot of SQL. If i need to typecast to use
> an index then i have to see how to do this with this framework.
It's worth pointing out that this problem
explain analyze SELECT --columns-- FROM KEY_VALUE_META_DATA t0 WHERE
t0.ID_FOREIGN_TABLE = 21110::bigint;
an index is used. Very fine, the performance is about 10 to 100 times
faster for the single select.
An alternative technique is to do this:
... t0.ID_FOREIGN_TABLE = '21110';
Chris
-
On Monday 05 January 2004 17:48, David Teran wrote:
> Hi,
>
> > The performance will likely to be the same. Its just that integer
> > happens to
> > be default integer type and hence it does not need an explicit
> > typecast. ( I
> > don't remember exactly which integer is default but it is either
Hi,
The performance will likely to be the same. Its just that integer
happens to
be default integer type and hence it does not need an explicit
typecast. ( I
don't remember exactly which integer is default but it is either of
int2,int4
and int8...:-))
The docs say int4 is much faster than int8
On Monday 05 January 2004 17:35, David Teran wrote:
> explain analyze SELECT --columns-- FROM KEY_VALUE_META_DATA t0 WHERE
> t0.ID_FOREIGN_TABLE = 21110;
>
> i see that no index is being used whereas when i use
>
> explain analyze SELECT --columns-- FROM KEY_VALUE_META_DATA t0 WHERE
> t0.ID_FOREIGN
Hi Shridhar,
Are you sure you are using correct data types on indexes?
Did not know about this...
e.g. if field1 is an int2 field, then following query would not use an
index.
our fk have the type bigint, when i try one simple select like this:
explain analyze SELECT --columns-- FROM KEY_VALU
On Monday 05 January 2004 16:58, David Teran wrote:
> We have some tests to check the performance and FrontBase is about 10
> times faster than Postgres. We already played around with explain
> analyse select. It seems that for large tables Postgres does not use an
> index. We often see the scan me
Hi,
we are new to Postgres and we are evaluating Postgres 7.4 on MacOS X as
an alternative to FrontBase 3.6.27.
From the available features Postgres is the choice #1.
We have some tests to check the performance and FrontBase is about 10
times faster than Postgres. We already played around with
17 matches
Mail list logo
