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
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
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
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
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
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
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
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, 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
>
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
[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
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
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
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
[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
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] 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 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
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.
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 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
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
-
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
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
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
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
---
>
> 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
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;
Aggregate (cost=1
29 matches
Mail list logo
