Stephen Frost wrote:
> > And it's completely unnecessary. For example, I have set my majordomo
> > preferences for the postgresql.org lists not to send me copies of emails
> > where I am also in the To: or Cc: lines. After doing that I get no
> > duplicates.
>
> This doesn't help at all, ac
Stephen Frost wrote:
Andrew,
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
For example, because it put *my* address in the list for your message
above, it caused my MUA quite correctly to add a To: line to myself,
which I certainly didn't want to do.
Honestly, I suspect thunderbird
Andrew,
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
> For example, because it put *my* address in the list for your message
> above, it caused my MUA quite correctly to add a To: line to myself,
> which I certainly didn't want to do.
Honestly, I suspect thunderbird just doesn't know your addr
Stephen Frost wrote:
(BTW, why does your MUA set Mail-Followup-To: (and do it badly, what's
more) ?)
I'm amazed at the number of people who ask me this.. Guess it's just
different for different communities. Basically, I like to keep my mail
in the different folders it belongs in, s
"Stephen Frost" <[EMAIL PROTECTED]> writes:
> I'd rather get responses to my emails through the list than directly to me.
> Additionally, I don't really need to get two copies of every email sent to
> me on a mailing list.
Then doesn't setting it to:
Andrew Dunstan <[EMAIL PROTECTED]>,PostgreS
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
>> Seems like that'd make more sense the changing it to use the child
>> tables directly.. Just my 2c.
>
> This is actually a technique already used elsewhere in the app, so it
> will fit quite well. Thanks for the suggestion, though.
Sure.
> (BTW, w
Stephen Frost wrote:
* Gregory Stark ([EMAIL PROTECTED]) wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
Actual execution of the query in question was talking one tenth of that
time.
...
but in principle it seems silly to keep paying the same penalty over and
over again.
* Gregory Stark ([EMAIL PROTECTED]) wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>
> > Actual execution of the query in question was talking one tenth of that
> > time.
> >...
> > but in principle it seems silly to keep paying the same penalty over and
> > over again.
>
> I would think c
On Fri, 2008-05-09 at 08:47 -0400, Andrew Dunstan wrote:
> Yesterday a client and I were sad to discover that the overhead of
> constraint exclusion is apparently O(n) in the number of partitions, and
> that where we had ~180 partitions each with a simple constraint (check
> (field = nnn)) the
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Actual execution of the query in question was talking one tenth of that
> time.
>...
> but in principle it seems silly to keep paying the same penalty over and
> over again.
I would think constraint_exclusion only really makes sense if you're spendin
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Yesterday a client and I were sad to discover that the overhead of
> constraint exclusion is apparently O(n) in the number of partitions, and
> that where we had ~180 partitions each with a simple constraint (check
> (field = nnn)) the overhead appear
On Fri, 2008-05-09 at 08:47 -0400, Andrew Dunstan wrote:
> However, I wondered if we couldn't mitigate this by caching the results
> of constraint exclusion analysis for a particular table + condition. I
> have no idea how hard this would be, but in principle it seems silly to
> keep paying the
Yesterday a client and I were sad to discover that the overhead of
constraint exclusion is apparently O(n) in the number of partitions, and
that where we had ~180 partitions each with a simple constraint (check
(field = nnn)) the overhead appeared to amount to about 0.25s on some
quite perfor
13 matches
Mail list logo
