On Wed, Jun 10, 2015 at 2:08 PM, Merlin Moncure wrote:
> On Wed, Jun 10, 2015 at 3:55 PM, Patrick Krecker wrote:
>> OK. Well, fortunately for us, we have a lot of possible solutions this
>> problem, and it sounds like actually getting statistics for attributes
>> ? 'r
OK. Well, fortunately for us, we have a lot of possible solutions this
problem, and it sounds like actually getting statistics for attributes
? 'reference' is not realistic. I just wanted to make sure it wasn't
some configuration error on our part.
Can anyone explain where exactly the estimate for
Hi everyone --
I had an issue the other day where a relatively simple query went from
taking about 1 minute to execute to taking 19 hours. It seems that the
planner chooses to use a materialize sometimes [1] and not other times
[2]. I think the issue is that the row count estimate for the result
o
On Wed, Dec 10, 2014 at 2:44 AM, Maila Fatticcioni
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello.
> I need to tune a postgres installation I've just made to get a better
> performance. I use two identical servers with a hot replication
> configuration. The two servers have the
Hi all -- I am trying to do a better job of understanding why the
planner chooses some plans over others, and I ran into this issue this
morning where the planner ends up choosing a query that's 15000x
slower. I have a table that represents nodes (here called
"components") in a tree. Each node has
Hey everyone --
I am debugging an issue with our Postgres machine running on EC2. We are
experiencing slowness when retrieving about 14k rows from a larger table of
140MM rows. Initially I thought it was an indexing problem (doing VACUUM
FULL reduced the index size from 12gb to 8gb), but the slown
