Re: [HACKERS] Idea for reducing planning time

2001-02-28 Thread Tatsuo Ishii
Tatsuo Ishii [EMAIL PROTECTED] writes: Tom, do you have a plan to make a back patch for 7.0.3? No, I don't. No time for it now. I got a bug report from a user with a script to reproduce the problem. Seems the backend consumes infinite memory. Not infinite, surely ;-) ... but

Re: [HACKERS] Idea for reducing planning time

2001-02-27 Thread Tatsuo Ishii
Bruce Momjian [EMAIL PROTECTED] writes: If you like I'll post the patch, but it strikes me as a waste of list bandwidth --- anyone who is likely to actually review it is perfectly capable of doing cvs diff for themselves ... Posting patch is only useful if you want people to review it.

Re: [HACKERS] Idea for reducing planning time

2001-02-27 Thread Tom Lane
Tatsuo Ishii [EMAIL PROTECTED] writes: Tom, do you have a plan to make a back patch for 7.0.3? No, I don't. No time for it now. I got a bug report from a user with a script to reproduce the problem. Seems the backend consumes infinite memory. Not infinite, surely ;-) ... but possibly more

Re: TOAST-table vacuuming (was Re: [HACKERS] Idea for reducing planning time)

2000-12-17 Thread Hiroshi Inoue
"Mikheev, Vadim" wrote: Also, is TOAST-table vacuuming fixed now? Still broken. Hiroshi had muttered something about fixing the internal commit of VACUUM so that it's more like a real commit --- including advancing the transaction ID --- but still doesn't release the exclusive lock

Re: [HACKERS] Idea for reducing planning time

2000-12-15 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Totally agree. In the old days, we posted all our patches to the list so people could see. We used to make cvs commits only on the main server, so we had the patch handy, and it made sense to post it. Now that we have remote cvs, we don't do it as

Re: [HACKERS] Idea for reducing planning time

2000-12-15 Thread Marc G. Fournier
On Fri, 15 Dec 2000, Alfred Perlstein wrote: * Bruce Momjian [EMAIL PROTECTED] [001215 10:34] wrote: sorry, meant to respond to the original and deleted it too fast ... Tom, if the difference between 7.0 and 7.1 is such that there is a performance decrease, *please* apply the

RE: [HACKERS] Idea for reducing planning time

2000-12-15 Thread Mikheev, Vadim
It seems that Tom has committed his fixups but we're still waiting on Vadim? Sorry guys, I'm busy with WAL issues currently. CRC will require initdb, so it's better to implement it first... Also, is TOAST-table vacuuming fixed now? Vadim

Re: [HACKERS] Idea for reducing planning time

2000-12-15 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: If you like I'll post the patch, but it strikes me as a waste of list bandwidth --- anyone who is likely to actually review it is perfectly capable of doing cvs diff for themselves ... Posting patch is only useful if you want people to review it. They

Re: [HACKERS] Idea for reducing planning time

2000-12-15 Thread Alfred Perlstein
* Bruce Momjian [EMAIL PROTECTED] [001215 10:34] wrote: sorry, meant to respond to the original and deleted it too fast ... Tom, if the difference between 7.0 and 7.1 is such that there is a performance decrease, *please* apply the fix ... with the boon that OUTER JOINs will

RE: TOAST-table vacuuming (was Re: [HACKERS] Idea for reducing planning time)

2000-12-15 Thread Mikheev, Vadim
Also, is TOAST-table vacuuming fixed now? Still broken. Hiroshi had muttered something about fixing the internal commit of VACUUM so that it's more like a real commit --- including advancing the transaction ID --- but still doesn't release the exclusive lock held by VACUUM. Basically

Re: [HACKERS] Idea for reducing planning time

2000-12-15 Thread Bruce Momjian
[ Charset ISO-8859-1 unsupported, converting... ] It seems that Tom has committed his fixups but we're still waiting on Vadim? Sorry guys, I'm busy with WAL issues currently. CRC will require initdb, so it's better to implement it first... Also, is TOAST-table vacuuming fixed now? Can

Re: [HACKERS] Idea for reducing planning time

2000-12-15 Thread Bruce Momjian
Bruce Momjian [EMAIL PROTECTED] writes: If you like I'll post the patch, but it strikes me as a waste of list bandwidth --- anyone who is likely to actually review it is perfectly capable of doing cvs diff for themselves ... Posting patch is only useful if you want people to review it.

RE: [HACKERS] Idea for reducing planning time

2000-12-15 Thread Mikheev, Vadim
Sorry guys, I'm busy with WAL issues currently. CRC will require initdb, so it's better to implement it first... Also, is TOAST-table vacuuming fixed now? Can someone please remind me? CRC allows us to know of WAL log is corrupt? Currently WAL has no means to know is log data

[HACKERS] Idea for reducing planning time

2000-12-13 Thread Tom Lane
I've been looking into Brian Hirt's complaint that 7.0.3 and 7.1 are lots slower than 7.0.2 in planning big joins. The direct cause is that since we now deduce implied equality clauses, the system has more potential join paths than it used to --- for example, given "WHERE a.x = b.y AND b.y =

Re: [HACKERS] Idea for reducing planning time

2000-12-13 Thread Alfred Perlstein
* Tom Lane [EMAIL PROTECTED] [001213 15:18] wrote: I'm trying to resist the temptation to make this change right now :-). It's not quite a bug fix --- well, maybe you could call it a performance bug fix --- so I'm kind of thinking it shouldn't be done during beta. OTOH I seem to have lost

Re: [HACKERS] Idea for reducing planning time

2000-12-13 Thread The Hermit Hacker
sorry, meant to respond to the original and deleted it too fast ... Tom, if the difference between 7.0 and 7.1 is such that there is a performance decrease, *please* apply the fix ... with the boon that OUTER JOINs will provide, would hate to see us with a performance hit reducing that impact

Re: [HACKERS] Idea for reducing planning time

2000-12-13 Thread Tom Lane
Alfred Perlstein [EMAIL PROTECTED] writes: If you're saying that you're OK with the work Vadim has done please let him know, I'm assuming he hasn't committed out of respect for your still standing objection. Well, I'm still against committing it now, but I only have one core vote, and I seem