Hi Francisco,
Generally, PG sorting is much slower than hash aggregation for performing
the distinct operation. There may be small sizes where this isn¹t true, but
for large amounts of data (in-memory or not), hash agg (used most often, but
not always by GROUP BY) is faster.
We¹ve implemented a
Pablo Alcaraz <[EMAIL PROTECTED]> writes:
> We have a database running smoothly for months. 2 days ago I get this
> error message. I tried a restore, a full restore (deleting the old
> database and recovering from backup all the information) but we are
> getting this error every time.
I think y
Hi All!
We have a database running smoothly for months. 2 days ago I get this
error message. I tried a restore, a full restore (deleting the old
database and recovering from backup all the information) but we are
getting this error every time.
In this case I got this error when I was trying
Hello,
I need wo advice on vacuum settings.
I have a quad core X5355 @ 2.66GHz with 8 Go of memory
1Q) Why autovaccum does not work, I have set the value to on in
postgresql.conf but when the server start it's still off
2Q) Here are my settings for vacuum, could you help me to optimise
PFC writes:
- If you process up to some percentage of your RAM worth of data, hashing
is going to be a lot faster
Thanks for the excellent breakdown and explanation. I will try and get sizes
of the tables in question and how much memory the machines have.
- If you need DISTINCT ON
Gregory Stark writes:
HashAggregate needs to store more values in memory at the same time so it's
not a good plan if you have a lot of distinct values.
So far the resulting number of rows where in the thousands and the source
data were in there hundreds of thousands and the group by was faste
Greg Smith wrote:
If you write a giant block of writes, those tend to be sorted by the
OS and possibly the controller to reduce total seeks. That's a pretty
efficient write and it can clear relatively fast.
But if you're been trickling writes in an unstructured form and in low
volume, there
