Hello,
Let's say TableA has "toastable" column, the contents of this column is
stored in let's say pg_toast_1234.
Is there a query to find which records (chunk_id, chunk_seq) in
pg_toast_1234 store data for specific record in TableA (i.e. with PK
column value eq. '567')?
Igor Neyman
On Montag, 25. Januar 2010 Kevin Grittner wrote:
> Have a look at reltoastrelid:
Hmm.. select * from pg_class; doesnt give anything containing 1910021
that I had in the log. So what? A temporary table? But that shouldn't be
bloated nor auto-vacuumed, right?
--
mit freundlichen Grüssen,
Michae
Michael Monnerie wrote:
> such a bloat can't happen in a day.
That is evidence that you may have a problem with some long-running
transaction which stays open for days, possibly "idle in
transaction". Bloat will accumulate, without any vacuum being able
to prevent it or recover from it, until
On Mon, Jan 25, 2010 at 05:33:10PM +0200, Julius Tuskenis wrote:
> Thank you for your answer Kevin.
>> create index tblname_username_latin on tblname
>> ((fnk_latin(username)));
>>
> Tried this, but with no changes
>> You might want to have that function force all letters to lowercase.
>>
>
On Montag, 25. Januar 2010 Kevin Grittner wrote:
> Any chance you had or have long-running transactions. We once had
> very low free space in a big database which suddenly ballooned. It
> turned out an application programmer had left a connection in "idle
> in transaction" state for a few days.
>
Thank you for your answer Kevin.
create index tblname_username_latin on tblname
((fnk_latin(username)));
Tried this, but with no changes
You might want to have that function force all letters to lowercase.
Tried that too, but seem to me that ILIKE doesn't use the index. I'm
using usern
Michael Monnerie wrote:
> So, as there was that one relation that was bloatet - how could it
> be? Autovaccuum, nightly vacuum analyze, weekly cluster - and
> still a heavy bloated toast* something. I must do something wrong.
Any chance you had or have long-running transactions. We once had
v
On Montag, 25. Januar 2010 Kevin Grittner wrote:
> Michael Monnerie wrote:
> > why did postgres suddenly decide to remove the old cruft suddenly?
>
> Have you read through this yet?:
>
> http://www.postgresql.org/docs/8.3/interactive/runtime-config-resourc
> e.html#RUNTIME-CONFIG-RESOURCE-FSM
Y
Michael Monnerie wrote:
> why did postgres suddenly decide to remove the old cruft suddenly?
Have you read through this yet?:
http://www.postgresql.org/docs/8.3/interactive/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-FSM
> Autovacuum is on, the nightly backups do an extra "vacuum
Julius Tuskenis wrote:
> I've made a function that converts lithuanian letters to latin and
> use it like fnk_latin(username) ILIKE fnk_latin('kestas').
> Now the problem is performance.
> Maybe some special index would help?
create index tblname_username_latin on tblname
((fnk_latin(usern
Hello
I have a task to make postgres find user records no matter if they are
spelled correctly. In particular I have to find names with Lithuanian
letters even if the user searches using latin letters. For example
search criteria 'kestas' should find 'Kęstas'. I've made a function that
conver
I got this log on 8.3.9:
Jan 24 02:13:28 db23.zmi.at postgres[29696]: [3-1] DB= U= H= WARNING:
relation "pg_toast.pg_toast_1910021" contains more than "max_fsm_pages"
pages with useful free space
Jan 24 02:13:28 db23.zmi.at postgres[29696]: [3-2] DB= U= H= HINT:
Consider using VACUUM FULL on
12 matches
Mail list logo
