Hi
we have a table with about 4 million rows. One column has an int value,
there is a btree index on it. We tried to execute the following
statement and it is very slow on a dual G5 2GHZ with 4 GB of RAM.
explain analyze select count(*) from job_property where int_value = 0;
Aggregate (cost=1
Hello,
If you has index on id, then you can use
SELECT id FROM tabulka ORDER BY id DESC LIMIT 1;
See 4.8. FAQ
Regards
Pavel Stehule
On Wed, 11 Feb 2004, David Teran wrote:
> Hi
>
> we have a table with about 4 million rows. One column has an int value,
> there is a btree index on it. We t
>
> Hi
>
> we have a table with about 4 million rows. One column has an int value,
> there is a btree index on it. We tried to execute the following
> statement and it is very slow on a dual G5 2GHZ with 4 GB of RAM.
>
> explain analyze select count(*) from job_property where int_value = 0;
>
> Ag
Hi,
Is your int_value data type int4? If not then use "... from
job_property
where int_value = '0'"
Indexes are used only if datatypes matches.
tried those variations already. Strange enough, after dropping and
recreating the index everything worked fine.
regards David
---
Had you done a VACUUM ANALYZE at all? There has been much discussion
lately about the planner needing to be updated to know that the index
is a better choice.
On Feb 11, 2004, at 6:32 AM, David Teran wrote:
Hi,
Is your int_value data type int4? If not then use "... from
job_property
where in
hello
i have postgres 7.3.2.,linux redhat 9.0
a database,and 20 tables
a lot of fields are char(x)
when i have to make update for all the fields except index
postgres works verry hard
what should i've changed in configuration to make it work faster
thanks
bogdan
---(end of b
my data base is very slow. The machine is a processor Xeon 2GB with
256 MB of RAM DDR. My archive of configuration is this:
#
# PostgreSQL configuration file
# -
#
# This file consists of lines of the f
On Wed, 11 Feb 2004 [EMAIL PROTECTED] wrote:
> somebody please knows to give tips to me to increase the
> performance
Run VACUUM ANALYZE. Find one query that is slow. Run EXPLAIN ANALYZE on
that query. Read the plan and figure out why it is slow. Fix it.
--
/Dennis Björklund
-
On Feb 11, 2004, at 7:23 AM, [EMAIL PROTECTED] wrote:
#
# Optimizer Parameters
#
enable_seqscan = false
enable_indexscan = false
enable_tidscan = false
enable_sort = false
enable_nestloop = false
enable_mergejoin = false
enable_hashjoin = false
Why did you disable *every* type of query metho
Oops! [EMAIL PROTECTED] (Pavel Stehule) was seen spray-painting on a wall:
>
> Regards
> Pavel Stehule
>
> On Wed, 11 Feb 2004, David Teran wrote:
>
>> Hi
>>
>> we have a table with about 4 million rows. One column has an int value,
>> there is a btree index on it. We tried to execute the followi
On Wed, 2004-02-11 at 09:23, [EMAIL PROTECTED] wrote:
> my data base is very slow. The machine is a processor Xeon 2GB with
> 256 MB of RAM DDR. My archive of configuration is this:
I'm not surprised. New values below old.
> sort_mem = 131072 # min 64, size in KB
sort_mem = 8192.
On Feb 11, 2004, at 7:23 AM, [EMAIL PROTECTED] wrote:
my data base is very slow. The machine is a processor Xeon 2GB with
256 MB of RAM DDR. My archive of configuration is this:
After looking through the configuration some more, I would definitely
recommend getting rid of your current postgresq
[EMAIL PROTECTED] wrote:
my data base is very slow. The machine is a processor Xeon 2GB with
256 MB of RAM DDR. My archive of configuration is this:
This is a joke, right?
chris
---(end of broadcast)---
TIP 6: Have you searched our list archives
On Wed, 11 Feb 2004, David Teran wrote:
> Hi,
>
> > Is your int_value data type int4? If not then use "... from
> > job_property
> > where int_value = '0'"
> > Indexes are used only if datatypes matches.
> >
> tried those variations already. Strange enough, after dropping and
> recreating the i
[EMAIL PROTECTED] writes:
> my data base is very slow. The machine is a processor Xeon 2GB with
> 256 MB of RAM DDR. My archive of configuration is this:
> sort_mem = 131072 # min 64, size in KB
> #vacuum_mem = 8192 # min 1024, size in KB
Change it back to 8192, or perh
the normal queries do not present problems, but all the ones
that join has are very slow.
OBS: I am using way ODBC. He will be that they exist some
configuration specifies inside of the same bank or in the ODBC?
Quoting Rod Taylor <[EMAIL PROTECTED]>:
> On Wed, 2004-02-11 at 09:23, [EMAIL PROT
On Wed, 11 Feb 2004, stefan bogdan wrote:
> hello
> i have postgres 7.3.2.,linux redhat 9.0
> a database,and 20 tables
> a lot of fields are char(x)
> when i have to make update for all the fields except index
> postgres works verry hard
> what should i've changed in configuration to make it work
If my boss came to me and asked me to make my database server run as
slowly as possible, I might come up with the exact same postgresql.conf
file as what you posted.
Just installing the default postgresql.conf that came with postgresql
should make this machine run faster.
Read this:
http://ww
[EMAIL PROTECTED] writes:
> the normal queries do not present problems, but all the ones
> that join has are very slow.
No surprise, as you've disabled all but the stupidest join algorithm...
As others already pointed out, you'd be a lot better off with the
default configuration settings than wit
I already came back the old conditions and I continue slow in the same
way!
Quoting Tom Lane <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] writes:
> > the normal queries do not present problems, but all the ones
> > that join has are very slow.
>
> No surprise, as you've disabled all but the stupides
On Wed, 11 Feb 2004, scott.marlowe wrote:
> On Wed, 11 Feb 2004, stefan bogdan wrote:
>
> > hello
> > i have postgres 7.3.2.,linux redhat 9.0
> > a database,and 20 tables
> > a lot of fields are char(x)
> > when i have to make update for all the fields except index
> > postgres works verry hard
>
the version is 7.3.2 in a connective 9.
the hen foot is without nails at the moment: =)
|
/|\
this is a principal table of system:
CREATE TABLE public.compra_prod_forn
(
nu_seq_prod_forn numeric(12) NOT NULL,
cd_fabricante numeric(6),
cd_moeda numeric(4) NOT NULL,
cd_compra numeric(12) N
On Wed, 11 Feb 2004 [EMAIL PROTECTED] wrote:
> I already came back the old conditions and I continue slow in the same
> way!
OK, we need some things from you to help troubleshoot this problem.
Postgresql version
schema of your tables
output of "explain analyze your query here"
a chicken foot (ha
On Wed, 2004-02-11 at 12:15, [EMAIL PROTECTED] wrote:
> I already came back the old conditions and I continue slow in the same
> way!
Dumb question, but did you restart the database after changing the
config file?
---(end of broadcast)---
TIP 5: Ha
First thing I would check is to make sure all those foreign keys are the
same type.
Second, make sure you've got indexes to go with them. I.e. on a multi-key
fk, have a multi-key index.
On Wed, 11 Feb 2004 [EMAIL PROTECTED] wrote:
> the version is 7.3.2 in a connective 9.
> the hen foot is w
Is there a way to automatically coerce an int into a bigint for
indexing purposes?
We have a table with a bigint column that is an index.
For mi, there's no problem, since I now know to say
select * from foo where id = 123::bigint
but our casual users still say
select * from foo whe
Mark Harrison <[EMAIL PROTECTED]> writes:
> Is there a way to automatically coerce an int into a bigint for
> indexing purposes?
This problem is fixed in CVS tip.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe a
If things are still slow after you have checked your keys as indicated,
then pick one query and post the output from EXPLAIN ANALYZE for the
list to examine.
oh - and ensure you are *not* still using your original postgresql.conf :-)
best wishes
Mark
scott.marlowe wrote:
First thing I would
Is your int_value data type int4? If not then use "... from
job_property
where int_value = '0'"
Indexes are used only if datatypes matches.
tried those variations already. Strange enough, after dropping and
recreating the index everything worked fine.
Has that table been updated a lot in its
29 matches
Mail list logo
