[Tobias Brox - Tue at 06:04:34PM +0200]
> (...) and at one
> point in the code I'm even asking the database for "explain plan", grepping
> out the estimated cost number, and referring the user to take contact with
> the IT-dept if he really needs the report. But I digress.
I just came to think ab
Dumping a database which contains a table with a bytea
column takes approximately 25 hours and 45 minutes. The database has 26
tables in it. The other 25 tables take less than 5 minutes to dump so almost
all time is spent dumping the bytea table.
prd1=# \d ybnet.ebook_master;
Tab
On Tue, Aug 02, 2005 at 12:19:30PM -0400, Tom Lane wrote:
> Tobias Brox <[EMAIL PROTECTED]> writes:
> > Is there any ways to give postgresql a hint that a
> > particular SQL call should be run at lower priority? Since every db
> > connection has a pid, I can manually run "renice" to scheduele it b
The short question:
Is there any ways to give postgresql a hint that a
particular SQL call should be run at lower priority? Since every db
connection has a pid, I can manually run "renice" to scheduele it by the OS
- but of course I can't do it manually all the time.
The long story:
We have a
Tom Lane wrote:
Tobias Brox <[EMAIL PROTECTED]> writes:
Is there any ways to give postgresql a hint that a
particular SQL call should be run at lower priority? Since every db
connection has a pid, I can manually run "renice" to scheduele it by the OS
- but of course I can't do it manually all
Tobias Brox <[EMAIL PROTECTED]> writes:
> Is there any ways to give postgresql a hint that a
> particular SQL call should be run at lower priority? Since every db
> connection has a pid, I can manually run "renice" to scheduele it by the OS
> - but of course I can't do it manually all the time.
A
Tom,
Thanks for pointing it out. I made the small required modifications to match
copy.c version 1.247 and sent it to -patches list. New patch is V16.
Alon.
On 8/1/05 7:51 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> "Alon Goldshuv" <[EMAIL PROTECTED]> writes:
>>> This patch appears to reverse
Thanks Tom,
That modifies the query plan slightly, but the planner still decides to
do a hash join for the lte_user table aliased 't'. Though, if I
make this change and set enable_hashjoin to off, the query plan (and
execution time) gets even better.
enable_hashjoin = on
