"Phoenix Kiula" <[EMAIL PROTECTED]> writes:
> 2. Is there a production equivalent of REINDEX? Last time I tried
> CREATE INDEX CONCURRENTLY overnight, by the morning it had croaked
> with these errors:
> ERROR: deadlock detected
> DETAIL: Process 6663 waits for ShareLock on transaction 999189656
> On Fri, Nov 14, 2008 at 12:57:32PM +0800, Phoenix Kiula wrote:
>> 1. If I have a unique index on (user_id, url_encrypted), then will
>> queries asking only for user_id also use this index? Or should i
>> simply have separate indexes on user_id and url_encrypted? I vaguely
>> recall reading somewh
> Thanks Tomas.
>
>
>> The table may still be bloated - the default autovacuum parameters may
>> not
>> be agressive enough for heavily modified tables.
>
>
> My autovacuum settings:
>
>
> autovacuum = on
> autovacuum_vacuum_cost_delay = 20
> vacuum_cost_delay= 20
> au
On Fri, Nov 14, 2008 at 9:22 PM, Hoover, Jeffrey <[EMAIL PROTECTED]> wrote:
> "There were 2132065 unused item pointers."
>
> Looks to me like a large update or insert failed on this table
Thanks. So what can I do? I have reindexed all indexes already!
--
Sent via pgsql-general mailing list
Thanks Tomas.
> The table may still be bloated - the default autovacuum parameters may not
> be agressive enough for heavily modified tables.
My autovacuum settings:
autovacuum = on
autovacuum_vacuum_cost_delay = 20
vacuum_cost_delay= 20
autovacuum_naptime
>> 8.4 seconds is a very long time to spend looking up a single record.
>> Is this table bloated? What does
>>
>> vacuum verbose books;
>>
>> say about it? Look for a line like this:
>>
>> There were 243 unused item pointers
>
> Thanks but this table "books" has autovac on, and it's manually
> va
On Fri, Nov 14, 2008 at 12:57:32PM +0800, Phoenix Kiula wrote:
> 1. If I have a unique index on (user_id, url_encrypted), then will
> queries asking only for user_id also use this index? Or should i
> simply have separate indexes on user_id and url_encrypted? I vaguely
> recall reading somewhere th
On Fri, Nov 14, 2008 at 10:57 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Yeah, but note that the planner knows darn well that this will be an
> expensive query --- 493427.14 cost units estimated to fetch 2 rows!
>
> My interpretation is that the condition on user_id is horribly
> nonselective (at
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> On Thu, Nov 13, 2008 at 2:04 PM, Phoenix Kiula <[EMAIL PROTECTED]> wrote:
>> explain analyze SELECT alias, id, title, private_key, aliasEntered
>> FROM books
>> WHERE user_id = 'MYUSER' AND url_encrypted =
>> 'bed59c2f2d92e306d4481a276bd8a78c4b0532d4'
Phoenix Kiula escribió:
> >>
> >> Index Scan using new_idx_books_userid on books (cost=0.00..493427.14
> >> rows=2 width=31) (actual time=0.428..8400.299 rows=1 loops=1)
> >> Index C
Thanks Scott. Responses below.
>>
>> (1) The culprit SELECT sql is (note that "MYUSER" in this example can
>> be an IP address) --
>
> So, it can be, but might not be? Darn, If it was always an ip I'd
> suggest changing types.
>
Yes, it can either be a registered USER ID or an IP address. I
On Thu, Nov 13, 2008 at 2:04 PM, Phoenix Kiula <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 14, 2008 at 3:10 AM, Scott Marlowe <[EMAIL PROTECTED]> wrote:
>> On Thu, Nov 13, 2008 at 11:59 AM, Phoenix Kiula <[EMAIL PROTECTED]> wrote:
>>> Hi.
>>>
>>> I had tweaked my PG 8.2.6 with the very kind help of th
On Fri, Nov 14, 2008 at 3:10 AM, Scott Marlowe <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 13, 2008 at 11:59 AM, Phoenix Kiula <[EMAIL PROTECTED]> wrote:
>> Hi.
>>
>> I had tweaked my PG 8.2.6 with the very kind help of this list a
>> couple years ago. It has been working fine, until recently. Not sur
On Thu, Nov 13, 2008 at 11:59 AM, Phoenix Kiula <[EMAIL PROTECTED]> wrote:
> Hi.
>
> I had tweaked my PG 8.2.6 with the very kind help of this list a
> couple years ago. It has been working fine, until recently. Not sure
> if it is after the update to 8.3 or because my DB has been growing,
> but th
Hi.
I had tweaked my PG 8.2.6 with the very kind help of this list a
couple years ago. It has been working fine, until recently. Not sure
if it is after the update to 8.3 or because my DB has been growing,
but the db is very slow now and the cache doesn't seem enough.
~ > free -m
total used free
15 matches
Mail list logo
