In fact, getting rid of vacuum full, or changing it to work like
cluster, has been proposed in the past. The use case really is pretty
narrow; cluster is a lot faster if there's a lot of unused space in the
table, and if there's not, vacuum full isn't going to do much so there's
not much point
Just a random thought/question...
Are you running else on the machine? When you say resource usage, do
you mean hd space, memory, processor, ???
What are your values in top?
More info...
Cheers
Anton
On 27/08/2007, Bill Moran [EMAIL PROTECTED] wrote:
In response to Chris Mair [EMAIL PROTECTED]:
Hi,
Sorry but I couldn't find the answer to this...
I would like to empty all stats (pg_stat_all_tables probably mostly)
so I can get an idea of what's going on now. Is this possible? I
didn't want to just go deleting without knowing what it would do...
Thanks
Anton
--
echo
On 20/12/2007, Alvaro Herrera [EMAIL PROTECTED] wrote:
Anton Melser escribió:
Hi,
Sorry but I couldn't find the answer to this...
I would like to empty all stats (pg_stat_all_tables probably mostly)
so I can get an idea of what's going on now. Is this possible? I
didn't want to just
Hi,
>Changing the locale to anything other than C or POSIX will
> have a performance overhead. I’m pretty sure that just declaring the
> locale on the indexes is just like plastering over the cracks.
>
>
>
> Is it possible to reload the database with the same locale as the
Hi,
It is looking like some missing optimization that was removed from RC
> release.
>
Thanks. Is there some discussion of why these optimisations were removed? I
started looking at some of the more complicated queries I do and there are
many occasions where there are 10-30x performance
Hi,
I moved a DB between two "somewhat" similar Postgres installs and am
getting much worse plans on the second. The DB was dumped via pg_dump
(keeping indexes, etc.) and loaded to the new server.
The first (installed via emerge):
select version();
PostgreSQL 9.4rc1 on x86_64-pc-linux-gnu,
>
> I'd bet your old database is in C locale and the new one is not.
>
Remind me never to never bet against you :-).
> The LIKE optimization requires an index that's sorted according to plain
> C (strcmp) rules. A regular text index will be that way only if the
> database's LC_COLLATE is C.
>
>
> Declaring new indexes with COLLATE "C" and removing the old indexes fixed
>> the like problem but it created a another - the > and < queries need a sort
>> before passing off the the new index. Having two indexes seems to give me
>> the best of both worlds, though obviously it's taking up
