Re: [GENERAL] Speed of conversion from int to bigint

On Wed, 27 Sep 2017 11:31:54 +0200 Tomas Vondra wrote: > On 09/27/2017 10:08 AM, Jonathan Moules wrote: > > Hi, > > (Postgres 9.5 and 9.6) > > We have a table of about 650million rows. It's a partitioned table, with > > two "child" tables. We want to change its primary key type from int to > > bi

Re: [GENERAL] Speed of conversion from int to bigint

Tomas's suggestion definitely is the better if you're altering the type of a single column. If you need to make more extensive changes to the table structure, copying usually is the better way to go. George -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes

Re: [GENERAL] Speed of conversion from int to bigint

On Wed, 27 Sep 2017 09:08:25 +0100, Jonathan Moules wrote: >Hi, >(Postgres 9.5 and 9.6) >We have a table of about 650million rows. It's a partitioned table, >with two "child" tables. We want to change its primary key type >from int to bigint while retaining the current values. > >We're using this

Re: [GENERAL] Speed of conversion from int to bigint

On 09/27/2017 10:08 AM, Jonathan Moules wrote: > Hi, > (Postgres 9.5 and 9.6) > We have a table of about 650million rows. It's a partitioned table, with > two "child" tables. We want to change its primary key type from int to > bigint while retaining the current values. > > We're using this: >

Re: [GENERAL] Speed up Switchover

On 2013-07-25 22:00:23 -0700, Sergey Konoplev wrote: > On Thu, Jul 25, 2013 at 1:03 AM, TJ wrote: > > I am looking for a way of speeding up the process of switching over of > > severs. > > At the moment we are switching over via the trigger file, reconfiguring our > > applications, patching or upd

Re: [GENERAL] Speed up Switchover

On Thu, Jul 25, 2013 at 11:00 PM, Samrat Revagade wrote: >>> secondary without having to rsync the data as it can take up to 10 hours. >> >> pg_rewind (https://github.com/vmware/pg_rewind) is what you need. > > But I think it has a problem regarding the hint bits which Robert Hass > pointed out. >

Re: [GENERAL] Speed up Switchover

On Fri, Jul 26, 2013 at 3:00 PM, Samrat Revagade wrote: > > secondary without having to rsync the data as it can take up to 10 hours. > > pg_rewind (https://github.com/vmware/pg_rewind) is what you need. > > But I think it has a problem regarding the hint bits which Robert Hass > pointed out. > Yo

Re: [GENERAL] Speed up Switchover

> secondary without having to rsync the data as it can take up to 10 hours. pg_rewind (https://github.com/vmware/pg_rewind) is what you need. But I think it has a problem regarding the hint bits which Robert Hass pointed out. You can still solve hint bit problem by enabling new checksum feature,

Re: [GENERAL] Speed up Switchover

On Thu, Jul 25, 2013 at 1:03 AM, TJ wrote: > I am looking for a way of speeding up the process of switching over of > severs. > At the moment we are switching over via the trigger file, reconfiguring our > applications, patching or updating the old primary and rsyncing the data > over to the old p

Re: [GENERAL] Speed of lo_unlink vs. DELETE on BYTEA

At 07:43 25/09/2011, Reuven M. Lerner wrote: Hi, everyone. Daniel Verite wrote: It would thus appear that there's a slight edge for dumping bytea, but nothing super-amazing. Deleting, however, is still much faster with bytea than large objects. The pro

Re: [GENERAL] Speed of lo_unlink vs. DELETE on BYTEA

Hi, everyone.  Daniel Verite wrote: How much bytea are you dumping for it to take only 0.066s? The fact that it takes about the same time than dumping the "empty content" looks very suspicious. On my desktop machine, if I create a table with 1000 blobs conta

Re: [GENERAL] Speed of lo_unlink vs. DELETE on BYTEA

Reuven M. Lerner wrote: > 1.1 1,000 records > == > > DeleteDump > ---+-+ > Empty content 0.172s0.057s > bytea 0.488s0.066s > large object30.833s 9.275s How much bytea are you dum

Re: [GENERAL] Speed of lo_unlink vs. DELETE on BYTEA

Hi, everyone. Albe wrote: Could you try with a trigger instead of a rule and see if the performance is better? Yours, Laurenz Albe Great idea.  I did that, and here are the results for 10,000 records: |   | Delete    |

Re: [GENERAL] Speed of lo_unlink vs. DELETE on BYTEA

Reuven M. Lerner wrote: > When a record in the main table is deleted, there is a rule (yes a rule -- > not a trigger) in the > referencing table that performs a lo_unlink on the associated object. > I just want to check that my intuition is correct: Wouldn't it be way faster > and more efficien

Re: [GENERAL] Speed of lo_unlink vs. DELETE on BYTEA

Hi again, everyone.  I'm replying to my own posting, to add some information: I decided to do some of my own benchmarking.  And if my benchmarks are at all accurate, then I'm left wondering why people use large objects at all, given their clunky API and their extremely sl

Re: [GENERAL] speed up restore from dump

On Friday 31 October 2008 08:07:08 Sam Mason wrote: > On Thu, Oct 30, 2008 at 02:28:38PM -0700, Alan Hodgson wrote: > > On Thursday 30 October 2008, Joao Ferreira > > <[EMAIL PROTECTED]> > > > > wrote: > > > well. see for yourself... (360 RAM , 524 SWAP) that's what it is... > > > it supposed t

Re: [GENERAL] speed up restore from dump

On Thu, 2008-10-30 at 13:08 -0700, Alan Hodgson wrote: > On Thursday 30 October 2008, Joao Ferreira gmail > > During restore: > > # vmstat > > procs memory--- ---swap-- -io -system-- cpu > > r b swpd free buff cache si so bi bo in cs us sy id wa > > 3

Re: [GENERAL] speed up restore from dump

On Thu, Oct 30, 2008 at 02:28:38PM -0700, Alan Hodgson wrote: > On Thursday 30 October 2008, Joao Ferreira <[EMAIL PROTECTED]> > wrote: > > well. see for yourself... (360 RAM , 524 SWAP) that's what it is... > > it supposed to be somewhat an embedded product... > > Clearly your hardware is yo

Re: [GENERAL] speed up restore from dump

On Thursday 30 October 2008, Joao Ferreira <[EMAIL PROTECTED]> wrote: > well. see for yourself... (360 RAM , 524 SWAP) that's what it is... > it supposed to be somewhat an embedded product... > Clearly your hardware is your speed limitation. If you're swapping at all, anything running on the

Re: [GENERAL] speed up restore from dump

Alan Hodgson wrote: > On Thursday 30 October 2008, Joao Ferreira gmail > > During restore: > > # vmstat > > procs memory--- ---swap-- -io -system-- cpu > > r b swpd free buff cache si so bi bo in cs us sy id wa > > 3 1 230204 4972 1352 110128 2

Re: [GENERAL] speed up restore from dump

On Thursday 30 October 2008, Joao Ferreira gmail > During restore: > # vmstat > procs memory--- ---swap-- -io -system-- cpu > r b swpd free buff cache si so bi bo in cs us sy id wa > 3 1 230204 4972 1352 110128 21 17 63 24 56 12 2 85

Re: [GENERAL] speed up restore from dump

On Thu, Oct 30, 2008 at 07:28:57PM +, Joao Ferreira gmail wrote: > On Thu, 2008-10-30 at 11:39 -0700, Alan Hodgson wrote: > > You're probably just > > disk-bound, though. What does vmstat say during the restore? > > During restore: > # vmstat > procs memory--- ---swap-- -io--

Re: [GENERAL] speed up restore from dump

On Thu, 2008-10-30 at 11:39 -0700, Alan Hodgson wrote: > On Thursday 30 October 2008, Joao Ferreira gmail > <[EMAIL PROTECTED]> wrote: > > What other cfg paramenters shoud I touch ? > > work_mem set to most of your free memory might help. I've raised work_mem to 128MB. still get the same 20 m

Re: [GENERAL] speed up restore from dump

On Thursday 30 October 2008, Joao Ferreira gmail <[EMAIL PROTECTED]> wrote: > What other cfg paramenters shoud I touch ? work_mem set to most of your free memory might help. You're probably just disk-bound, though. What does vmstat say during the restore? -- Alan -- Sent via pgsql-general ma

Re: [GENERAL] Speed up repetitive queries

thout the sql word in the name. Thanks a lot for your help! Javier -Original Message- From: Scott Marlowe [mailto:[EMAIL PROTECTED] Sent: Sunday, 04. May, 2008 06:20 To: Javier Olazaguirre Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] Speed up repetitive queries On Fri, May 2

Re: [GENERAL] Speed up repetitive queries

On Fri, May 2, 2008 at 9:13 AM, Javier Olazaguirre <[EMAIL PROTECTED]> wrote: > > I have an application developped by a third party which takes very long to > process all the queries. > > I use Red Hat 4 and Postgre 8.2.7 on a 64 bit machine. > > Checking the log files created by postgre I see tha

Re: [GENERAL] speed up insert query

Tom Hart wrote: Martin Gainty wrote: 2 things tr_tran_time needs to be already in 'time format' is_ok needs to be indexed (preferably bitmapped index) HTH/ Martin The data is COPY'ed from csv's that our internal software creates, and we don't have control over output format. Is coaxing tr_t

Re: [GENERAL] speed up insert query

Martin Gainty wrote: 2 things tr_tran_time needs to be already in 'time format' is_ok needs to be indexed (preferably bitmapped index) HTH/ Martin The data is COPY'ed from csv's that our internal software creates, and we don't have control over output format. Is coaxing tr_tran_time into pr

Re: [GENERAL] speed up insert query

2 things tr_tran_time needs to be already in 'time format' is_ok needs to be indexed (preferably bitmapped index) HTH/ Martin - Original Message - From: "Tom Hart" <[EMAIL PROTECTED]> To: "Postgres General List" Sent: Monday, November 26, 2007 5:30 PM Subject: [GENERAL] speed up insert qu

Re: [GENERAL] Speed of postgres compared to ms sql, is this article/comment

On Wed, Jan 17, 2007 at 09:41:03AM -0800, novnov wrote: > > There is another blog article comparing postgresql with mysql, where the > postgres is slow thing is repeated and the benchmark tends to confirm. The > blogger is new to postgres and does not represent the test as definative. > > http://

Re: [GENERAL] Speed of postgres compared to ms sql, is this article/comment

There is another blog article comparing postgresql with mysql, where the postgres is slow thing is repeated and the benchmark tends to confirm. The blogger is new to postgres and does not represent the test as definative. http://wskills.blogspot.com/2007/01/postgresql-vs-mysql-benchmark.html Fir

Re: [GENERAL] Speed of postgres compared to ms sql, is this

2006/12/6, Markus Schiltknecht <[EMAIL PROTECTED]>: Hi, Tomi N/A wrote: >> > When the subselect returns a lot of results, pgsql really takes it's >> time. > > 8.1.something PostgreSQL 8.2 improved a lot for IN clauses with lots of values. I think it now performs as good as an equal join query.

Re: [GENERAL] Speed of postgres compared to ms sql, is this

> I didn't notice this kind of sensitivity with MSSQL, but again, I > can't easily reproduce what I've been doing. Funny, although it was better at the IN type of query, so the difference was not as great, MSSQL also typically did better with the query expressed as a join--older versions, I haven'

Re: [GENERAL] Speed of postgres compared to ms sql, is this

These sorts of reports would be far more helpful if they contained some specifics. What queries does MSSQL do better than Postgres, exactly? Our OR-patch was inspired by our customer migrating from MS SQL to postgres. Next, index support of IS NULL. And, there is a huge difference in performan

Re: [GENERAL] Speed of postgres compared to ms sql, is this

Hi, Tomi N/A wrote: > When the subselect returns a lot of results, pgsql really takes it's time. 8.1.something PostgreSQL 8.2 improved a lot for IN clauses with lots of values. I think it now performs as good as an equal join query. Regards Markus ---(end of broa

Re: [GENERAL] Speed of postgres compared to ms sql, is this

2006/12/5, Scott Marlowe <[EMAIL PROTECTED]>: On Tue, 2006-12-05 at 16:32, Tomi N/A wrote: > One type of query does come to mind, now that I think about it. > pgsql has trouble handling queries like > SELECT * FROM t0 WHERE t0.id_t1 IN (SELECT t1.id FROM t1 WHERE...) > When the subselect return

Re: [GENERAL] Speed of postgres compared to ms sql, is this

On Tue, 2006-12-05 at 16:32, Tomi N/A wrote: > One type of query does come to mind, now that I think about it. > pgsql has trouble handling queries like > SELECT * FROM t0 WHERE t0.id_t1 IN (SELECT t1.id FROM t1 WHERE...) > When the subselect returns a lot of results, pgsql really takes it's time

Re: [GENERAL] Speed of postgres compared to ms sql, is this

2006/12/5, Tom Lane <[EMAIL PROTECTED]>: These sorts of reports would be far more helpful if they contained some specifics. What queries does MSSQL do better than Postgres, exactly? You are of course correct, Tom. I'm sorry I'm not in a position to replay what I've been doing a year ago...I w

Re: [GENERAL] Speed of postgres compared to ms sql, is this

I suppose comparing postgres running on a single processor laptop to sql server running on a dual processor machine wouldn't help you determine what sql server does better. If it might let me know. Aside from maybe having the planner reorder joins for you I would guess that it is sql servers s

Re: [GENERAL] Speed of postgres compared to ms sql, is this

"Tomi N/A" <[EMAIL PROTECTED]> writes: > 2006/12/4, Ian Harding <[EMAIL PROTECTED]>: >> Amen. When I migrated from MSSQL to PostgreSQL (4 years ago), I found >> out exactly how seriously MS SQL coddles you when it comes to its "Oh, >> I know what you really meant" query planning. I committed some

Re: [GENERAL] Speed of postgres compared to ms sql, is this

2006/12/4, Ian Harding <[EMAIL PROTECTED]>: On 11/13/06, Scott Marlowe <[EMAIL PROTECTED]> wrote: > On Mon, 2006-11-13 at 15:36, novnov wrote: > > OK, thanks everyone, I gather from the responses that postgres performance > > won't be an issue for me then. If MS SQL Server and Postgres are in the

Re: [GENERAL] Speed of postgres compared to ms sql, is this

On 11/13/06, Scott Marlowe <[EMAIL PROTECTED]> wrote: On Mon, 2006-11-13 at 15:36, novnov wrote: > OK, thanks everyone, I gather from the responses that postgres performance > won't be an issue for me then. If MS SQL Server and Postgres are in the same > ballpark performance-wise, which seems to

Re: [GENERAL] Speed of postgres compared to ms sql, is this

t; From: novnov [mailto:[EMAIL PROTECTED] > To: pgsql-general@postgresql.org > Sent: Sat, 11 Nov 2006 20:15:08 -0500 > Subject: Re: [GENERAL] Speed of postgres compared to ms sql, is this > > > I agree with what you say. And I'd still be interesting in hearing of >

Re: [GENERAL] Speed of postgres compared to ms sql, is this

On Mon, 2006-11-13 at 15:36, novnov wrote: > OK, thanks everyone, I gather from the responses that postgres performance > won't be an issue for me then. If MS SQL Server and Postgres are in the same > ballpark performance-wise, which seems to be the upshot of your comments, no > problem. I'd only h

Re: [GENERAL] Speed of postgres compared to ms sql, is this

PostgreSQL follows SQL compliance, as does MS SQL Server. 'complicated queries' are left to the creativity of the SQL'er - squeler ;) There are of course proprietary differences in 'enhancements.' Some things that you can write in MS SQL, don't apply to Oracle/PostgreSQL/MySQL and many permutat

Re: [GENERAL] Speed of postgres compared to ms sql, is this

OK, thanks everyone, I gather from the responses that postgres performance won't be an issue for me then. If MS SQL Server and Postgres are in the same ballpark performance-wise, which seems to be the upshot of your comments, no problem. I'd only have worried if there was something like the major

Re: [GENERAL] Speed of postgres compared to ms sql, is this

On 11/11/06, novnov <[EMAIL PROTECTED]> wrote: I agree with what you say. And I'd still be interesting in hearing of first hand experience with the speed of the two databases from someone who is 'good' at both. The article commentor was obviously not a pgsql expert. I've heard recently that pgsq

Re: [GENERAL] Speed of postgres compared to ms sql, is this

On Sat, 2006-11-11 at 19:15, novnov wrote: > I agree with what you say. And I'd still be interesting in hearing of first > hand experience with the speed of the two databases from someone who is > 'good' at both. The article commentor was obviously not a pgsql expert. I've > heard recently that pgs

Re: [GENERAL] Speed of postgres compared to ms sql, is this

From: novnov [mailto:[EMAIL PROTECTED]To: pgsql-general@postgresql.orgSent: Sat, 11 Nov 2006 20:15:08 -0500Subject: Re: [GENERAL] Speed of postgres compared to ms sql, is this I agree with what you say. And I'd still be interesting in hearing of first hand experience with the speed of th

Re: [GENERAL] Speed of postgres compared to ms sql, is this

I agree with what you say. And I'd still be interesting in hearing of first hand experience with the speed of the two databases from someone who is 'good' at both. The article commentor was obviously not a pgsql expert. I've heard recently that pgsql is as fast as mysql, so it seems odd that ms sq

Re: [GENERAL] Speed of postgres compared to ms sql, is this article/comment off?

novnov <[EMAIL PROTECTED]> writes: > http://www.simple-talk.com/sql/sql-server-2005/sql-server,-postgressql-and-fish-curry/ > at the bottom of the page is a post by Andrew Clarke that says pgsql is much > slower in comparison to ms sql. With no details, it's hard to rate that as anything but conte

Re: [GENERAL] Speed problems

On Wed, 2005-09-14 at 21:06, John Fabiani wrote: > On Wednesday 14 September 2005 08:23, Scott Marlowe wrote: > > > OK. But how many are you updating between regular vacuums? That's the > > real issue. If your regular vacuums aren't often enough, postgresql > > starts lengthening the tables ins

Re: [GENERAL] Speed problems

On Wednesday 14 September 2005 08:23, Scott Marlowe wrote: > OK. But how many are you updating between regular vacuums? That's the > real issue. If your regular vacuums aren't often enough, postgresql > starts lengthening the tables instead of reusing the space in them that > was freed by the l

Re: [GENERAL] Speed problems

> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Scott Marlowe > Sent: Wednesday, September 14, 2005 8:24 AM > To: Warren Bell > Cc: pgsql-general@postgresql.org > Subject: Re: [GENERAL] Speed problems > > > On Tue, 20

Re: [GENERAL] Speed problems

On Tue, 2005-09-13 at 21:01, Warren Bell wrote: > >On Tue, 2005-09-13 at 13:20, Warren Bell wrote: > >> I am having problems with performance. I think this is a simple question > and > >> I am in the right place, if not, please redirect me. > >> > >> I have a table with 36 fields that slows down qu

Re: [GENERAL] Speed problems

>On Tue, 2005-09-13 at 13:20, Warren Bell wrote: >> I am having problems with performance. I think this is a simple question and >> I am in the right place, if not, please redirect me. >> >> I have a table with 36 fields that slows down quite a bit after some light >> use. There are only 5 clients

Re: [GENERAL] Speed problems

When you say VACUUM do you really mean VACUUM ANALYZE? Have you tried a simple ANALYZE? I'm assuming of course that you have indexes that you want to use Warren Bell wrote: I am having problems with performance. I think this is a simple question and I am in the right place, if not, pl

Re: [GENERAL] Speed problems

On Tue, 2005-09-13 at 13:20, Warren Bell wrote: > I am having problems with performance. I think this is a simple question and > I am in the right place, if not, please redirect me. > > I have a table with 36 fields that slows down quite a bit after some light > use. There are only 5 clients conne

Re: [GENERAL] Speed problems

"Warren Bell" <[EMAIL PROTECTED]> writes: > I have a table with 36 fields that slows down quite a bit after some light > use. There are only 5 clients connected to this DB and they are doing mostly > inserts and updates. There is no load on this server or db at all. This > table has had no more tha

Re: [GENERAL] speed of communication and pgsql development

t: Re: [GENERAL] speed of communication and pgsql development There is an IRC channel already on EFnet... Visit #postgresql. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Gowey, Geoffrey Sent: Saturday, August 25, 2001 8:35 PM To: '[EMAIL PROTECTED

Re: [GENERAL] speed of communication and pgsql development

There is an IRC channel already on EFnet... Visit #postgresql. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Gowey, Geoffrey Sent: Saturday, August 25, 2001 8:35 PM To: '[EMAIL PROTECTED]' Subject: [GENERAL] speed of communication and pgsql development

Re: [GENERAL] speed of communication and pgsql development

> On Sun, 26 Aug 2001, Lamar Owen wrote: > > > On Saturday 25 August 2001 23:34, Gowey, Geoffrey wrote: > > > Not to whine or anything, but I really do think that pgsql development > > > seriously could be helped by usage of an official irc channel. > > > > While chat is usable for some things, d

Re: [GENERAL] speed of communication and pgsql development

Bruce Momjian wrote: >We are on #postgresql on Efnet. Have been for years, and mentioned in >the FAQ. Very good for getting development help. I was working with >the PAM patch author there today. > Ugg. I'd rather setup a bot to relay to irc.openprojects.net. EFnet is a sickly beast that ca

Re: [GENERAL] speed of communication and pgsql development

On Sunday 26 August 2001 00:56, Gowey, Geoffrey wrote: > Why efnet? They're the only people that I know that still require identd. > Unfortunately, I would have to reconfigure the firewall here just so I can > get on that net. Has anyone else run in to this problem or am I the only > one sitting

Re: [GENERAL] speed of communication and pgsql development

On Saturday 25 August 2001 23:34, Gowey, Geoffrey wrote: > Not to whine or anything, but I really do think that pgsql development > seriously could be helped by usage of an official irc channel. While chat is usable for some things, doing development when developers are on different schedules or

Re: [GENERAL] speed of communication and pgsql development

> Not to whine or anything, but I really do think that pgsql development > seriously could be helped by usage of an official irc channel. Whether it > be hosted on pgsql's official servers or on a 3rd party network such as > undernet or openprojects.net I leave as a matter of discussion, but the

RE: [GENERAL] speed of communication and pgsql development

> Why efnet? They're the only people that I know that still require identd. > Unfortunately, I would have to reconfigure the firewall here just so I can > get on that net. Has anyone else run in to this problem or am I the only > one sitting behind a firewall'd system? Some servers allow connec

RE: [GENERAL] speed of communication and pgsql development

al Message- From: speedboy [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 26, 2001 12:53 AM To: [EMAIL PROTECTED] Subject: Re: [GENERAL] speed of communication and pgsql development > Not to whine or anything, but I really do think that pgsql development > seriously could be helped by usag

Re: [GENERAL] speed of communication and pgsql development

> Not to whine or anything, but I really do think that pgsql development > seriously could be helped by usage of an official irc channel. efnet #postgresql ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

RE: [GENERAL] Speed...

some quick (and I might add disappointing) benchmark results... must tune.. . will be performing -and publishing results- of more comprehensive and rigorous suite on: - 2x700MHz cpu - 4GB RAM - 6x35GB 10k rpm RAID 5 system - linux 2.4.4 - postgres 7.1.2-2 I've perf-tuned many an oracle db -

Re: [GENERAL] speed on Postgresql compared to Mysql

"Livio Righetti" wrote: >Hi, > >Talking about insert, I know Mysql is fast than Postgresql. > >I've made the following test : > >40'000 insert (accouting context) using Perl and dbd : > >Postgresql : > text : 4 min 53 s > varchar : 4 min 49 s > char : 4 min

Re: [GENERAL] Speed of varchar vs. char in indices

* Mirko Zeibig <[EMAIL PROTECTED]> [010124 09:07] wrote: > Hello, > > I have a table: > > CREATE TABLE pge ( > pge_id SERIAL, > pge_pathCHAR(255) CONSTRAINT ak_pge_path UNIQUE, > PRIMARY KEY (pge_id) > ); > > >From other tables I now reference pge_id as well as pge_path. Somewher

Re: [GENERAL] Speed issues with update

Yup, a full VACUUM analyze was done on the table. The problem seems to be that 95% of processor time is spent in the kernal opening and closing the same table file. This does seem a little strange. Could this be a problem with the code? I've also tried a full reinstall, but to no avail. Loz On T

Re: [GENERAL] Speed issues with update

Lorenz, Have you run VACUUM on the table? Norman On Wednesday 01 November 2000 05:43 am, you wrote: > I'm using 'PostgreSQL 7.0.2 on i386-unknown-freebsdelf4.0, compiled by > cc'. > > The problem is that the following statement takes approx 3hrs on a table > with approx 136,000 records. > > upd

Re: [GENERAL] Speed difference between != and = operators?

Paul Caskey <[EMAIL PROTECTED]> writes: > This query takes 206 seconds: > [snip] > If I change the last line to this, it takes 1 second: What does EXPLAIN show for these queries? regards, tom lane

Re: [GENERAL] Speed difference between != and = operators?

Paul Caskey wrote: > > This query takes 206 seconds: > > SELECT t1.blah, t1.foo, t2.id > FROM t1, t2, t3 > WHERE t1.SessionId = 427 > AND t1.CatalogId = 22 > AND t1.CatalogId = t3.CatalogId > AND t2.id = t3.SomeId > AND t2.Active != 0 > > If I change the last line to this, it takes 1 second: >

Re: [GENERAL] Speed of locating tables?

Barry Lind <[EMAIL PROTECTED]> writes: > I am curious, how does PostgreSQL support tables larger than 2Gig, given > the file per table architecture? Multiple files per table ... regards, tom lane

RE: [GENERAL] Speed

Use Indexes... -DEJ > -Original Message- > From: Justin Long [SMTP:[EMAIL PROTECTED]] > Sent: Tuesday, April 27, 1999 11:31 AM > To: [EMAIL PROTECTED] > Subject: [GENERAL] Speed > > I find that it is actually faster to do a SELECT from a single record set, > then fetch eac