On Oct 4, 2006, at 10:47 AM, Nolan Cafferky wrote:
People ignorantly posting an unsubscribe to the list get this kind
of response because it's an annoyance to the list users,
Back in the day, a friend of mine setup an unsubscribe mailing list,
with open membership. The idea was if you saw so
On Oct 4, 2006, at 5:59 AM, Tobias Brox wrote:
[Csaba Nagy - Thu at 10:45:35AM +0200]
So you should check for "idle in transaction" sessions, those are
bad...
or any other long running transaction.
Thank you (and others) for pointing this out, you certainly set us on
the right track. We did
On Oct 4, 2006, at 11:35 AM, Csaba Nagy wrote:
On Wed, 2006-10-04 at 18:02, Csaba Nagy wrote:
If we didn't want to add it for each list we could just add a
link here:
http://www.postgresql.org/community/lists/subscribe
OK, now that I had a second look on that page, it does contain
unsubscri
On Oct 4, 2006, at 10:54 AM, Joshua D. Drake wrote:
[Joshua]
It is ridiculous that this community expects people to read email
headers to figure out how to unsubscribe from our lists.
I always check the headers when I want to unsubscribe from any
mailing
list, and I think most people on this
On Oct 4, 2006, at 4:40 PM, Ben wrote:
I'm surprised (though probably just because I'm ignorant) that it
would have so much sequential scanning in there. For instance,
because n is going to have at most a couple dozen rows, it seems
that instead of scanning all of public.track, it should be
Oh you hate explicit joins too? I started in Oracle and was dismayed to find
out what the SQL standard was. I especially miss the simplicity of += outer
joins.
I'll try adding the address_id index to facility_address and see what I get!
Carlo
""Merlin Moncure"" <[EMAIL PROTECTED]> wrote in me
"Carlo Stonebanks" <[EMAIL PROTECTED]> writes:
> Just to clarify: if I expect to join two tables that I expect to benfit from
> indexed scans, I should create indexes on the joined columns on BOTH sides?
Well, it all depends on the queries you plan to issue ... but for the
particular query shown
Just to clarify: if I expect to join two tables that I expect to benfit from
indexed scans, I should create indexes on the joined columns on BOTH sides?
Carlo
"Tom Lane" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Carlo Stonebanks" <[EMAIL PROTECTED]> writes:
>> I didn't cre
On 10/5/06, Carlo Stonebanks <[EMAIL PROTECTED]> wrote:
> do we have an multi-column index on
> facility_address(facility_id, address_id)? did you run analyze?
There is an index on facility_address on facility_id.
I didn't create an index on facility_address.address_id because I expected
joins
"Carlo Stonebanks" <[EMAIL PROTECTED]> writes:
> I didn't create an index on facility_address.address_id because I expected
> joins to go in the other direction (from facility_address to address).
Well, that's your problem right there ...
regards, tom lane
--
Steve Peterson <[EMAIL PROTECTED]> writes:
> The behavior also persists across a dump/reload of the table into a
> new install on a different machine. IIRC dump/reload rebuilds
> indexes from scratch.
Hm. There must be something you're not telling us that accounts for
the difference between th
> do we have an multi-column index on
> facility_address(facility_id, address_id)? did you run analyze?
There is an index on facility_address on facility_id.
I didn't create an index on facility_address.address_id because I expected
joins to go in the other direction (from facility_address to a
12 matches
Mail list logo
