... if we did, we could have told
> people how to use it to set the variables already. I'm very very
> suspicious of any suggestion that it's easy to derive appropriate
> numbers for these settings from one magic benchmark.
>
> regards, tom lane
>
> ---(end of broadcast)---
> TIP 6: explain analyze is your friend
--
Mike Benoit <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
valid transaction state - active SQL-transaction."
>
> /Dennis
>
> ---(end of broadcast)---
> TIP 6: explain analyze is your friend
--
Mike Benoit <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
gt; TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to [EMAIL PROTECTED] so that your
> message can get through to the mailing list cleanly
--
Mike Benoit <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
. Then the "big installations" can see that a major feature has
been in two stable releases (even if the time period was only a year)
and feel much more comfortable in upgrading. Why would they have to
upgrade more often then necessary anyways? Assuming security exploits
are back ported of
sub-transaction aren't we? To me that sounds
just as bad.
"ABORT ALL" sure would be nice.
--
Mike Benoit <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
l somewhere ...
>
> In any case, I think a target date should be set at the beginning of a
> dev cycle and a hard date should be set closer to the end of the cycle.
> Trying to adhere rigidly to a date set nine or twelve months previously
> doesn't strike me as good p
rror, Simon Riggs
>
>
> ---(end of broadcast)---
> TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
--
Mike Benoit <[EMAIL PROTECTED]>
---(end of broadcast)---
TI
Table:
Column | Type | Modifiers
---+---+-
imported_date | integer | not null default 0
PG v7.2.1 (nice and clean):
On Fri, 2002-11-29 at 13:22, Tom Lane wrote:
> Mike Benoit <[EMAIL PROTECTED]> writes:
> > I'm just curious, will your proposed in/exists optimizations help for
> > queries like:
>
> > db=# explain delete from dns_expired_domains where domain_id in (select
>
his will just waste cycles.)
>
> Anyone see a nice way to do this?
>
> regards, tom lane
>
> --(end of broadcast)--
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to [EMA
ke this feature very
nice.
--
Best Regards,
Mike Benoit
NetNation Communication Inc.
Systems Engineer
Tel: 604-684-6892 or 888-983-6600
---
Disclaimer: Opinions expressed here are my own and not
necessarily those of my employer
---
Some of you may be interested in this seemingly exhaustive benchmark
between ext2/3, ReiserFS, JFS, and XFS.
http://www.osdl.org/presentations/lwe-jgfs.pdf
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.post
I'm not a developer, but I know this item on the todo list has been a
magor pain in my side for quite a while:
# Make IN/NOT IN have similar performance to EXISTS/NOT EXISTS
[http://momjian.postgresql.org/cgi-bin/pgtodo?exists]
Any time I've attempted to use this feature, the query cost is in th
increase
> in size. Vacuum was run on database.
>
How did you calculate the size of database? If you used "du" make sure
you do it in the data/base directory as to not include the WAL files.
--
Best Regards,
Mike Benoit
NetNation Communication Inc.
Systems Engineer
Tel: 604
14 matches
Mail list logo
