This problem was caused by the OleDb driver. I used a 3rd party .NET
provider and it worked, 8000 rows in just over 100ms!
Can somebody send me a sample connection string for the PostGreSql native
.net driver please? I'm battling to find a valid connection string.
Thanks
--
Brenden,
> Any ideas what I can do to improve this without turning sequential
> scanning off?
Hmmm, looks like your row estimates are good. Which means it's probably your
postgresql.conf parameters which are off. Try the following, in the order
below:
1) Raise effective_cache_size to 2/3 o
Eric,
> Thank you , this might be a good solution , but we have a bigger upgrade
> comming for 8.1.x later on,
> but considering that other things out of our hands might occur , we
> might seriously look into it after fixing
> the current problems :) [because we dont think that upgrading right now
Oops. I forgot to mention that I was using PostgreSQL 8.1.3 on Mac OS X.Thanks, Brendan Duddridge | CTO | 403-277-5591 x24 | [EMAIL PROTECTED] ClickSpace Interactive Inc. Suite L100, 239 - 10th Ave. SE Calgary, AB T2G 0V9 http
Hi,I have a query that is using a sequential scan instead of an index scan. I've turned off sequential scans and it is in fact faster with the index scan.Here's my before and after.Before:ssdev=# SET enable_seqscan TO DEFAULT;ssdev=# explain analyze select cp.product_id from category_product cp, p
On Wednesday 29 March 2006 22:01, Craig A. James wrote:
> This is off-topic for this group so I'll just give a brief reply; I'm happy
> to carry on more just between the two of us...
>
> Gorshkov wrote:
> > That being said . what *is* the difference between coding a website -
> > major or other
This is off-topic for this group so I'll just give a brief reply; I'm happy to
carry on more just between the two of us...
Gorshkov wrote:
That being said . what *is* the difference between coding a website -
major or otherwise - in an "old-fashioned" compiled language and a
non-compiled l
On Wednesday 29 March 2006 21:23, Craig A. James wrote:
> Gorshkov wrote:
> > /flame on
> > if you were *that* worried about performance, you wouldn't be using PHP
> > or *any* interperted language
> > /flame off
> >
> > sorry - couldn't resist it :-)
>
> I hope this was just a joke. You should be
Gorshkov wrote:
/flame on
if you were *that* worried about performance, you wouldn't be using PHP or
*any* interperted language
/flame off
sorry - couldn't resist it :-)
I hope this was just a joke. You should be sure to clarify - there might be
some newbie out there who thinks you are ser
You should run the select query from the psql utility to determine if
it's PostgreSQL, or your OleDb driver that's being slow. It takes like
185ms on one of my tables to get 7000 rows.
Greg Quinn wrote:
how many rows does it return ? a few, or a lot ?
3000 Rows - 7 seconds - very slow
Whic
On Tuesday 28 March 2006 14:50, Scott Marlowe wrote:
> On Tue, 2006-03-28 at 13:42, PFC wrote:
> > > This is as much about the code in front of the database as the database
> > > itself. You'll want to use an architecture that supports pooled
> > > connections (java, php under lighttpd, etc...) an
> Hrm, you know that you -should- upgrade to at least the latest 7.4
> (7.4.13 I think is the most recent). looking from the
> changelogs, there are a few bugs that you could be hitting;
>
> 7.4.10
> * Fix race condition in transaction log management There
> was a narrow window in which an I
Eric Lauzon wrote:
Mabey later if this dosen't fix the problem , and as of information its
7.4.6 [i know its not the most rescent]
but it is the way it is right now and we suspect the problem might have
come from a power outage while there was
a full vacuum and the reason why its only one table
> -Original Message-
> From: Richard Huxton [mailto:[EMAIL PROTECTED]
> Sent: 29 mars 2006 17:10
> To: Eric Lauzon
> Cc: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Database possible corruption ,
> unsolvable mystery
>
> Eric Lauzon wrote:
> > This is why our investigation
Can you post an explain analyze for the delete query? That will at
least tell you if it is the delete itself which is slow, or a trigger /
referential integrity constraint check. Which version of PG is this?
-- Mark Lewis
On Wed, 2006-03-29 at 12:58 -0500, Eric Lauzon wrote:
> Greetings,
>
>
Eric Lauzon wrote:
This is why our investigation brought us to the folowing questions:
1. Are postgresql data file name are hashed references to table
name(as oracle)? [~path to data EX:/var/log/pgsql/data/[arbitraty
numbers]/[datafile]]?
OID numbers - look in the contrib directory/package for
Greetings,
We have an issue where we have a database with many tables.
The layout of the database is 3 set of look alike tables with different
names.
Each set of tables has some referential integrety that point back to
the main
control table.
On two set o
On Mar 28, 2006, at 11:55 AM, Marcos wrote:
The application will be a chat for web, the chats will be stored in
the
server. In a determined interval of time... more or less 2 seconds,
the
application will be looking for new messages.
We bought software for this purpose (phplive). It is b
On Mar 28, 2006, at 1:59 PM, Scott Marlowe wrote:
Generally you'll find the PostgreSQL gotchas are of the sort that make
you go "oh, that's interesting" and the MySQL gotchas are the kind
that
make you go "Dear god, you must be kidding me!"
But that's just my opinion, I could be wrong.
I
On Mar 28, 2006, at 1:57 PM, Madison Kelly wrote:
From what I understand, PostgreSQL is designed with stability and
reliability as key tenants. MySQL favors performance and ease of
use. An
From my point of view, mysql favors single-user performance over all
else. Get into multiple upda
On Wed, 29 Mar 2006 01:08:15 -0500
stef <[EMAIL PROTECTED]> threw this fish to the penguins:
>
> If your looking for suggestions, I would suggest updating the 8.1.x you
> have installed to the latest version, as of typing this is 8.1.3 ;) Most
> notable is some of the -bug- fixes that are in s
On 3/29/06, Greg Quinn <[EMAIL PROTECTED]> wrote:
> > how many rows does it return ? a few, or a lot ?
>
> 3000 Rows - 7 seconds - very slow
>
> Which client library may have a problem? I am using OleDb, though haven't
> tried the .NET connector yet.
esilo=# create temp table use_npgsql as select
On 3/28/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> Heh, too quick on the send button...
>
> On Tue, Mar 28, 2006 at 09:42:51PM +0200, PFC wrote:
> Actually, it's entirely possible to do stuff like web counters, you just
> want to do it differently in PostgreSQL. Simply insert into a table
> eve
Hi,
I've got this message while heavily inserting into a database. What
should I tune and how? It is postgresql 8.1.3.
2006-03-29 14:16:57.513 CEST:LOG: statistics buffer is full
Thanks in advance,
Akos
--
Üdvözlettel,
Gábriel Ákos
-=E-Mail :[EMAIL PROTECTED]|Web: http://www.i-logic.hu=-
-
3000 Rows - 7 seconds - very slow
On my PC (athlon 64 3000+ running Linux), selecting 3000 rows with 4
columns out of a 29 column table takes about 105 ms, including time to
transfer the results and convert them to native Python objects. It takes
about 85 ms on a test table with only th
Hi, Greg,
Greg Quinn wrote:
>>> I populate 3000 records into the table to test PostGreSql's speed.
>>> It takes about 3-4 seconds.
>> When you do the population, is it via inserts or copy?
> Via insert
Are those inserts encapsulated into a single transaction? If not, that's
the reason why it's so
how many rows does it return ? a few, or a lot ?
3000 Rows - 7 seconds - very slow
Which client library may have a problem? I am using OleDb, though haven't
tried the .NET connector yet.
Network configuration?? I am running it off my home PC with no network. It
is P4 2.4 with 1 Gig Ram. Win
On Fri, 2006-03-24 at 12:21, Jim C. Nasby wrote:
> On Thu, Mar 23, 2006 at 01:09:49PM +0200, Theo Kramer wrote:
> > ii If no to i, is it feasible to extend PostgreSQL to allow traversing
> >an index in column descending and column ascending order - assuming
> >an order by on more than one c
28 matches
Mail list logo
