Andrew Sullivan wrote:
On Sun, Apr 05, 2009 at 11:36:33AM -0700, Lists wrote:
*Slony-I* - I've used this in the past, but it's a huge pain to work
with, caused serious performance issues under heavy load due to long
running transactions (may not be the case anymore, it's been a while
si
I'm currently running 32bit FreeBSD so I can't really add more ram (PAE
doesn't work well under FreeBSD from what I've read) and there are
enough writes that more ram won't solve the problem completely.
However I will add plenty more ram next time I rebuild it.
Heikki Linnakangas wrote:
List
On Mon, Apr 6, 2009 at 8:50 AM, Mario Splivalo
wrote:
> Scott Marlowe wrote:
>>>
>>> CREATE INDEX photo_info_data_ix_field_value
>>> ON user_info_data USING btree (field_value);
>>>
>>> So, there is index on (user_id, field_name). Postgres is using index for
>>> user_id (...WHERE user_id = 12345)
Scott Marlowe wrote:
CREATE INDEX photo_info_data_ix_field_value
ON user_info_data USING btree (field_value);
So, there is index on (user_id, field_name). Postgres is using index for
user_id (...WHERE user_id = 12345) but not on field-name (...WHERE
field_name = 'f-spot'). When I add extra inde
On Mon, Apr 6, 2009 at 8:37 AM, Mario Splivalo
wrote:
> Scott Marlowe wrote:
>>
>> On Mon, Apr 6, 2009 at 6:20 AM, Mario Splivalo
>> wrote:
>>>
>>> Scott Marlowe wrote:
It's not really solved, it's just a happy coincidence that the current
plan runs well. In order to keep the quer
Scott Marlowe wrote:
On Mon, Apr 6, 2009 at 6:20 AM, Mario Splivalo
wrote:
Scott Marlowe wrote:
It's not really solved, it's just a happy coincidence that the current
plan runs well. In order to keep the query planner making good
choices you need to increase stats target for the field in the
On Mon, Apr 6, 2009 at 8:52 AM, Matthew Wakeling wrote:
> On Fri, 3 Apr 2009, Simon Riggs wrote:
>>
>> On Fri, 2009-04-03 at 10:04 -0400, Tom Lane wrote:
>>>
>>> Matthew Wakeling writes:
On Fri, 3 Apr 2009, Robert Haas wrote:
>
> Why not just use SQL to do the join?
Be
On Mon, Apr 6, 2009 at 6:20 AM, Mario Splivalo
wrote:
> Scott Marlowe wrote:
>>
>> It's not really solved, it's just a happy coincidence that the current
>> plan runs well. In order to keep the query planner making good
>> choices you need to increase stats target for the field in the index
>> ab
"Albe Laurenz" writes:
> roopasatish wrote:
>> I have an issue with the add foreign key constraint which
>> goes for waiting and locks other queries as well.
>>
>> ALTER TABLE ONLY holding_positions ADD CONSTRAINT
>> holding_positions_stock_id_fkey FOREIGN KEY (stock_id)
>> REFERENCES stocks (s
On Fri, 3 Apr 2009, Simon Riggs wrote:
On Fri, 2009-04-03 at 10:04 -0400, Tom Lane wrote:
Matthew Wakeling writes:
On Fri, 3 Apr 2009, Robert Haas wrote:
Why not just use SQL to do the join?
Because the merge condition is:
WHERE l1.start <= l2.end AND l2.start <= l1.end
and merge joins in
On Sun, Apr 05, 2009 at 11:36:33AM -0700, Lists wrote:
> *Slony-I* - I've used this in the past, but it's a huge pain to work
> with, caused serious performance issues under heavy load due to long
> running transactions (may not be the case anymore, it's been a while
> since I used it on a l
On Mon, 6 Apr 2009, Rainer Mager wrote:
The data should be mostly ordered by date. It is all logged in semi-realtime
such that 99% will be logged within an hour of the timestamp. Also, as
stated above, during this query it was about 1.2 MB/s, which I know isn't
great. I admit this isn't the best
Scott Marlowe wrote:
It's not really solved, it's just a happy coincidence that the current
plan runs well. In order to keep the query planner making good
choices you need to increase stats target for the field in the index
above. The easiest way to do so is to do this:
alter database mydb se
On Fri, 3 Apr 2009, Tom Lane wrote:
Simon Riggs writes:
On Fri, 2009-04-03 at 10:04 -0400, Tom Lane wrote:
I don't actually believe that a standard merge join algorithm will work
with an intransitive join condition ...
I think it's a common enough problem that having a non-standard join
alg
roopasatish wrote:
> I have an issue with the add foreign key constraint which
> goes for waiting and locks other queries as well.
>
> ALTER TABLE ONLY holding_positions ADD CONSTRAINT
> holding_positions_stock_id_fkey FOREIGN KEY (stock_id)
> REFERENCES stocks (stock_id) MATCH SIMPLE
>
On Mon, Apr 6, 2009 at 2:54 AM, roopasatish wrote:
>
> I have an issue with the add foreign key constraint which goes for waiting
> and locks other queries as well.
>
> ALTER TABLE ONLY holding_positions ADD CONSTRAINT
> holding_positions_stock_id_fkey FOREIGN KEY (stock_id)
> REFERENCES sto
On Sun, Apr 5, 2009 at 11:35 PM, Rainer Mager wrote:
>> -Original Message-
>> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> "Rainer Mager" writes:
>> >> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> >> Hmm ... it's pretty unusual to see the index fetch portion of a
>> bitmap
>> >> scan ta
Lists wrote:
Server is a dual core xeon 3GB ram and 2 mirrors of 15k SAS drives (1
for most data, 1 for wal and a few tables and indexes)
In total all databases on the server are about 10G on disk (about 2GB in
pgdump format).
I'd suggest buying as much RAM as you can fit into the server. RA
I have an issue with the add foreign key constraint which goes for waiting
and locks other queries as well.
ALTER TABLE ONLY holding_positions ADD CONSTRAINT
holding_positions_stock_id_fkey FOREIGN KEY (stock_id)
REFERENCES stocks (stock_id) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE N
19 matches
Mail list logo
