On Mon, 27 Oct 2003 15:32:41 -0800, Josh Berkus <[EMAIL PROTECTED]>
wrote:
>FROM event_types, events
> LEFT OUTER JOIN ...
>WHERE events.status = 1 or events.status = 11
> and events.event_date > '2003-10-27'
> and events.etype_id = event_types.etype_id
> and ( ...
>
This has probably been asked before, but I'll re-ask to spark debate on it again.
Is there any good reason to not have explain analyze also include information if
temporary files will be required on sorts, hashes, etc. during the processing of a
query. [Idea being setting your sort_mem won't be
I recalled seeing a thread on -HACKERS about some major improvements to the speed of
adding an FK to an existing table in 7.4. Naturally I was curious and decided to give
it a whirl. My findings are not too good. In fact, they are bad.
Could it be this patch never made it in?
Anyway, here's th
On Tue, 28 Oct 2003, Jeff wrote:
> I recalled seeing a thread on -HACKERS about some major improvements to
> the speed of adding an FK to an existing table in 7.4. Naturally I was
> curious and decided to give it a whirl. My findings are not too good. In
> fact, they are bad.
>
> Could it be this
Jeff <[EMAIL PROTECTED]> writes:
> I recalled seeing a thread on -HACKERS about some major improvements to the speed of
> adding an FK to an existing table in 7.4. Naturally I was curious and decided to
> give it a whirl. My findings are not too good. In fact, they are bad.
> 7.4b4, 10k shared b
[EMAIL PROTECTED] ("Kamalraj Singh Madhan") writes:
> Hi, I'am having major performance issues with post gre 7.3.1
> db. Kindly suggest all the possible means by which i can optimize
> the performance of this database. If not all, some ideas (even if
> they are common) are also welcome. There is no
On Tue, 28 Oct 2003 09:16:45 -0500
Jeff <[EMAIL PROTECTED]> wrote:
> 7.3.4: 328912ms [cpu pegged]
> 7.4b4: 298383ms [cpu pegged]
>
Just loaded up delicious 7.4b5 and wow...
sort_mem 8192: 137038ms [lots of tmp file activity]
sort_mem 256000: 83109ms
That's some good work there Lou, You'll
Manfred,
> Sorry, I have no answer to your question, but may I ask whether you
> really want to get presumably 106 output rows for each event with
> status 1?
>
> Or did you mean
>WHERE (events.status = 1 OR events.status = 11) AND ...
Thanks! I spent so much time tinkering around with
On 26 Oct, Bruce Momjian wrote:
> Mark Wong wrote:
>> > > Here are a pair of results where I just raise the load on the
>> > > database, where increasing the load increases the area of the database
>> > > touched in addition to increasing the transaction rate. The overall
>> > > metric increases s
FWIW: I'm fiddling with that right now, and the FK think was quick... a few
seconds... the tables in question have 1400 records, 343000 records and 7200
records... I'm running Beta5...
John.
On Tuesday 28 October 2003 10:21, Stephan Szabo wrote:
> On Tue, 28 Oct 2003, Jeff wrote:
> > I reca
On Tue, 28 Oct 2003, Jeff wrote:
> On Tue, 28 Oct 2003 09:16:45 -0500
> Jeff <[EMAIL PROTECTED]> wrote:
>
>
> > 7.3.4: 328912ms [cpu pegged]
> > 7.4b4: 298383ms [cpu pegged]
> >
>
> Just loaded up delicious 7.4b5 and wow...
>
> sort_mem 8192: 137038ms [lots of tmp file activity]
> sort_mem 256000
On Tue, 28 Oct 2003 10:32:36 -0800 (PST)
Stephan Szabo <[EMAIL PROTECTED]> wrote:
> Hmm, 298383 -> 83109 (since those are the 256k numbers). Not as
> much as I'd have hoped, but I'll take a factor of 3.
Yes. those are the numbers for 256MB of sort_mem.
It seemed to saturate the IO so once I get
John K. Herreshoff wrote:
> FWIW: I'm fiddling with that right now, and the FK think was quick... a few
> seconds... the tables in question have 1400 records, 343000 records and 7200
> records... I'm running Beta5...
Did those tables have analyze statistics? Can you try it without
statistic
I'm not sure about the analyze stats... Where would I find that (in
postgresql.conf I suppose) I'll go see what I have set up, and get back to
you in 30 minutes or less...
John.
On Tuesday 28 October 2003 13:34, Bruce Momjian wrote:
> John K. Herreshoff wrote:
> > FWIW: I'm fiddling with th
Hi,
suppose, for simplicity, there is a table with index like this:
create table TABLE1 (
A integer
);
create index TABLE1_A on TABLE1 (A);
My question is: why psql (7.3.3) does not use index when filtering by A IS
NULL, A IS NOT
NULL expressions?
In fact, I need to filter by expression ((A i
John K. Herreshoff wrote:
> I'm not sure about the analyze stats... Where would I find that (in
> postgresql.conf I suppose) I'll go see what I have set up, and get back to
> you in 30 minutes or less...
They are in pg_statistic. If you have ever anaylzed the table, there
are stats. I am in
That did not take long... about 13 minutes to reload the tables from an *.mdb
file, and a second or two for each of the 'alter table foo add foreign
key...' lines. I tried to drop a 'referencing' table, and the database would
not let me, said that something depended on it ;o)
Is there some way
> "GS" == Greg Stark <[EMAIL PROTECTED]> writes:
GS> At a guess the foreign key relationships you're enforcing don't
GS> have indexes to help them. If they do perhaps postgres isn't using
GS> them.
Or, if you do have indexes, they've bloated to be way too big and are
overwhelming your shared
> "J" == Jeff <[EMAIL PROTECTED]> writes:
J> And this leads to the place we'd get a huge benefit: Restoring
J> backups.. If there were some way to bump up sort_mem while doing
J> the restore.. things would be much more pleasant. [Although, even
There was a rather substantial thread on this a
John K. Herreshoff wrote:
> That did not take long... about 13 minutes to reload the tables from an *.mdb
> file, and a second or two for each of the 'alter table foo add foreign
> key...' lines. I tried to drop a 'referencing' table, and the database would
> not let me, said that something dep
On Tue, 28 Oct 2003 14:22:04 -0500
Vivek Khera <[EMAIL PROTECTED]> wrote:
> If you're restoring from a pg_dump -Fc (compressed dump) it already
> happens for you. The indexes and foreign keys are not added until the
> very end, from what I recall.
>
This happens with regular dumps - at the end
Just loaded up delicious 7.4b5 and wow...
sort_mem 8192: 137038ms [lots of tmp file activity]
sort_mem 256000: 83109ms
Hmm, 298383 -> 83109 (since those are the 256k numbers). Not as
much as I'd have hoped, but I'll take a factor of 3.
Hi Jeff,
Could you let us know the load times when you ha
22 matches
Mail list logo
