Prasanth <[EMAIL PROTECTED]> writes:
> PG Version: 7.4.7
> explain analyze select * from data where type_code >'2' AND type_code<'4';
> [ is slow ]
> explain analyze select * from data where type_code = '3';
> [ isn't ]
Are there a whole lot of rows with type_code = 2? If so, this is
fixed in 8.
PG Version: 7.4.7
OS: RedHat FC3
Below are two queries that would give the same results but amount of execution
time is so different.
explain analyze select * from data where type_code >'2' AND type_code<'4';
QUERY PLAN
About ASCII to Unicode conversion (if you have only Latin1 characters in
the database):
Here is a receipt, how you can do a charset conversion from SQL_ASCII into
UNICODE on the Linux side:
(check these from manual pages first!):
1. Stop PostgreSQL and make a good backup!
"su - postgres" ; "pg_du
The catastrophic error was the actual text sent from the IIS component
error.
SO I am not 100% sure what it means, I believe it is just mirroring back
text from the dbserver when trying to connect and failing.
I am guessing it is odbc and I am currently using the 7.4 version, but am
looking for t
Joel Fradkin wrote:
Hi,
I have been live for 4 days (vacuums run each night and backups done
each night).
Today around 2:30 PM EST my web app returned a catastrophic error.
Both web servers appeared to have the issue.
I could go on them and get data via pgadmin.
I could log on the server (IIS
If you could connect to the database server from the web server and get
data with PGAdmin then it doesn't' sound like a database or database
server problem. How is your web app connecting to the database? ODBC?
That might be a bit of an issue. PgAdmin doesn't use ODBC, it uses
libpq directl
Hi,
I have been live for 4 days (vacuums run each night and
backups done each night).
Today around 2:30 PM EST my web app
returned a catastrophic error.
Both web servers appeared to have the issue.
I could go on them and get data via pgadmin.
I could log on the server (IIS servers
Looks like you've tied into one of those Microsoft clone companies that
can't get off the Microslop stack. Have a similar problem with a
product here that will not work with anything other than Sql*slave and
if you hack it they won't support it. Best of luck. It also looks like
one of those "sm
On Thu, 2005-05-12 at 12:56, Kavan, Dan (IMS) wrote:
> Scott,
> If you had two applications that were each connecting to two different
> databases, have you found that it's beneficial to have to different
> instances of postgres running?
I haven't, but I could see where, if the workloads were ve
"Vishal Kashyap @ [SaiHertz]" <[EMAIL PROTECTED]> writes:
> In file included from preproc.y:6409:
> pgc.l: In function `yylex':
> pgc.l:920: error: `xsoip' undeclared (first use in this function)
Corrupted download maybe? That line refers to "xskip" not "xsoip".
regards,
Prasanth <[EMAIL PROTECTED]> writes:
> Seems like having int2 after code is doing the trick.
> Can you please explain the reasons behind this.
When you write "int2col > 2", the operator that is selected is int2-gt-int4.
However the index on an int2 column can only deal with int2-gt-int2.
8.0 gene
I have some clients that are looking to upgrade to MSSQL Server because
they use ACT!. I'm developing a web application for them that uses
PostgreSQL. Does anyone know if ACT! can use PostgreSQL? or if I can
hack it?
Suggestion welcome and Thanks,
J
---(end of broadcas
On Thu, 2005-05-12 at 12:46, Kavan, Dan (IMS) wrote:
> Do psql calls/procedures access resources reserved from the
> kernel.shmmax?
Only in the sense that it can execute a query, which in the backend
could therefore use shared memory. psql, itself, doesn't use shared
memory.
> How about the tar
Ok read about the indexes and type matches.
So is this fixed in 8.0?
Thanks,
-Prasanth.
Tom Lane wrote:
> Prasanth <[EMAIL PROTECTED]> writes:
>
>>code data type is int2.
>
>
> Ah-hah. So "where code > 2::int2" should work noticeably better for
> you. Or you could do "where code > '2'" to a
Scott,
If you had two applications that were each connecting to two different
databases, have you found that it's beneficial to have to different
instances of postgres running?
I have a few reasons why I think it would be better. One, it would be
beneficial to customize parameters for each appl
Do psql calls/procedures access resources reserved from the
kernel.shmmax?
How about the tar or copy sysadmin commands? I would guess they don't
use kernel.shmmax resources. Finally, work memory alos does not access
resources reserved from kernel.shmmax, correct? Thanks for clearing
things up.
Dear all ,
Got compile error for
postgresql-8.0.3
error is following
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wold-style-definition -Wendif-labels
-fno-strict-aliasing -Wno-error -pthread -D_REENTRANT -D_THREAD_SAFE
-D_POSIX_PTHREAD_SEMANTICS -I./../i
Thanks Tom.
Seems like having int2 after code is doing the trick.
Can you please explain the reasons behind this.
I Really appreciate your time.
Thanks,
-Prasanth.
Tom Lane wrote:
> Prasanth <[EMAIL PROTECTED]> writes:
>
>>code data type is int2.
>
>
> Ah-hah. So "where code > 2::int2" sho
Sorry seems like I am missing some thing here.
What is the difference between int2 & int4 as far as index scan is concerned?
I did try to update to 8.0 but it is not taking my dump from 7.4.7. If I
remember right it was complaining about pg_database being not present. I posted
a message on forums
Prasanth <[EMAIL PROTECTED]> writes:
> code data type is int2.
Ah-hah. So "where code > 2::int2" should work noticeably better for
you. Or you could do "where code > '2'" to avoid hard-wiring the data
type knowledge into your queries. Or just change it to int4 ;-)
Or update to 8.0.
code data type is int2.
I am sorry that I did not mention the version number
I am using 7.4.7.
Thanks,
-Prasanth.
Tom Lane wrote:
> Prasanth <[EMAIL PROTECTED]> writes:
>
>>A where condition I always use is shown below. This is bringing down the
>>number
>>of rows from 6.5m to 1210. I have an
EXPLAIN ANALYZE (SELECT id FROM a,b WHERE a.id = b.id AND code >2 AND
b.account_id = 16221);
QUERY PLAN
---
Merge Joi
Prasanth <[EMAIL PROTECTED]> writes:
> A where condition I always use is shown below. This is bringing down the
> number
> of rows from 6.5m to 1210. I have an index on code also. Even here it is going
> for seq scan.
> EXPLAIN ANALYZE SELECT count(*) fROM a where Code >2;
>
I agree with you.
But I have the where conditions on the tables I was expecting the planner to
user index scan but it went for seq scan.
I did a little testing using what you said.
Below are the results.
SELECT a.id FROM a,b WHERE a.id = b.id AND a.code >2 AND b.account_id = 16221;
Total runti
On Thu, 2005-05-12 at 10:51, Prasanth wrote:
> I agree with you.
>
> But I have the where conditions on the tables I was expecting the planner to
> user index scan but it went for seq scan.
>
> I did a little testing using what you said.
>
> Below are the results.
>
> SELECT a.id FROM a,b WHERE
Thanks for the prompt reply.
Table a has about 6 million and table b had a little more than half a million.
Sorry I wasn't exact about my numbers before.
I will be having the where conditions on both the tables that would bring down
the count drastically. Even in this case the planner is going f
On Thu, 2005-05-12 at 10:05, Prasanth wrote:
> When joining two tables the query plan is doing a seq scan rather than index
> scan. I do have indexes on the columns used for joining the tables.
>
> Example:
> SELECT a.id FROM a, b WHERE a.id = b.id;
>
>QUER
Guys i need some help.
Initially the connections to the database were 3 as seen using
netstat -a -n | grep "ESTAB" | grep
and ps -ef | grep postgres
After some time the connections suddenly incresed to 53 using the
above commands.
if i do
/usr/local/pgsql/bin/psql -d -c "select
c.relname,d.d
On Thu, 2005-05-12 at 10:10, Kavan, Dan (IMS) wrote:
> Hi Scott,
>
> Thanks again for all your tips.
>
> If I knock the buffer size down to 65,536 (still higher than what you
> are recommending) then my shmmax becomes:
> 256,000 + 550,292,685 (65536*8396.8) + 1,454,100 = 552,002,785
>
> That
Prasanth <[EMAIL PROTECTED]> writes:
> Hash Join (cost=13865.30..326413.23 rows=6451 width=18)
>Hash Cond: ("outer".id = "inner".id)
>-> Seq Scan on a (cost=0.00..125076.37 rows=6450937 width=18)
>-> Hash (cost=10168.64..10168.64 rows=500664 width=4)
> -> Seq Scan on b (
Hi Scott,
Thanks again for all your tips.
If I knock the buffer size down to 65,536 (still higher than what you
are recommending) then my shmmax becomes:
256,000 + 550,292,685 (65536*8396.8) + 1,454,100 = 552,002,785
That will leave me with 3.5 GB of free memory for the system & work
memory
On Wed, 2005-05-11 at 17:49, Chris Browne wrote:
> [EMAIL PROTECTED] (Scott Marlowe) writes:
>
> > On Wed, 2005-05-11 at 15:08, Ing. Jhon Carrillo wrote:
> >> I have a problem with the users administration. When I want to erase
> >> (drop) some databases there's an error: ** database "name_db" is
When joining two tables the query plan is doing a seq scan rather than index
scan. I do have indexes on the columns used for joining the tables.
Example:
SELECT a.id FROM a, b WHERE a.id = b.id;
QUERY PLAN
On Thu, May 12, 2005 at 00:23:05 +0200,
Enrico Weigelt <[EMAIL PROTECTED]> wrote:
> * Bruno Wolff III <[EMAIL PROTECTED]> wrote:
>
> > Maybe you can use client side certificates.
>
> how can they be used w/ psql ?
You should be able to get PAM to do this, but I haven't tried it to make sure.
Am Mittwoch, 11. Mai 2005 20:42 schrieb Brandon Fouts:
> I think for security reasons I should not run PostgreSQL from the root
yes.
> account. Also, as PostgreSQL will probably be only one of the applications
> running on this box. (would running in UML give me any extra security? - I
> suspect
35 matches
Mail list logo
