On Mon, Apr 15, 2013 at 1:59 PM, Anne Rosset wrote:
> I have this simple query that has performance issue. I am assuming there is
> something wrong in our configuration. Can someone point me to the right
> direction? (our work_mem is set to 64MB)
Why don't you try creating a functional index on
Hi all,
I have this simple query that has performance issue. I am assuming there is
something wrong in our configuration. Can someone point me to the right
direction? (our work_mem is set to 64MB)
srdb=> explain analyze 013-04-15 16:51:20,223 INFO
[com.vasoftware.sf.server.common.querygenera
On Mon, Apr 8, 2013 at 10:02 AM, Mark Davidson wrote:
> Been trying to progress with this today. Decided to setup the database on
> my local machine to try a few things and I'm getting much more sensible
> results and a totally different query plan http://explain.depesz.com/s/KGdin
> this case t
On Sun, Apr 7, 2013 at 3:22 PM, Mark Davidson wrote:
> Takes a little longer with the INNER join unfortunately. Takes about ~3.5
> minutes, here is the query plan http://explain.depesz.com/s/EgBl.
>
> With the JOIN there might not be a match if the data does not fall within
> one of the areas tha
On Fri, Apr 5, 2013 at 8:51 AM, Mark Davidson wrote:
> Hi All,
>
> Hoping someone can help me out with some performance issues I'm having
> with the INDEX on my database. I've got a database that has a data table
> containing ~55,000,000 rows which have point data and an area table
> containing ~
> You will want a select only workload in which all data fits in
> shared_buffers, and that doesn't do a round trip to some external driver
> program for each row selected.
>
> I proposed a patch for pgbench to add a new transaction of this nature last
> year under the subject "pgbench--new transac
