On 12/10/2013 01:45, BladeOfLight16 wrote:
On Fri, Oct 11, 2013 at 9:32 AM, Jesse Long j...@unknown.za.net
mailto:j...@unknown.za.net wrote:
explain select * from archive_document_index where node_id = 29
and value = 'BSH70002152';
QUERY PLAN
On 09/10/2013 18:06, Tom Lane wrote:
Jesse Long j...@unknown.za.net writes:
The query runs for much longer than I expect it to run for, and I think
this is due to it using the incorrect subplan. As you can see, subplans
1 and 3 make use of and index, but these subplans are not used.
Subplans
On 09/10/2013 15:20, Albe Laurenz wrote:
Jesse Long wrote:
There is no problem with row visibility, there is only one connection to
the database - the connection I am using to do these selects.
No idea why the plans cannot be used.
It might be helpful to see the table and index definitions
On 09/10/2013 18:06, Tom Lane wrote:
Jesse Long j...@unknown.za.net writes:
The query runs for much longer than I expect it to run for, and I think
this is due to it using the incorrect subplan. As you can see, subplans
1 and 3 make use of and index, but these subplans are not used.
Subplans
Hi PostgreSQL community,
I have the following query, run immediately after executing VACUUM in
the database. There is only one connection to the database.
The query runs for much longer than I expect it to run for, and I think
this is due to it using the incorrect subplan. As you can see,
On 09/10/2013 12:10, Albe Laurenz wrote:
Jesse Long wrote:
I have the following query, run immediately after executing VACUUM in
the database. There is only one connection to the database.
You should run ANALYZE, not VACUUM.
The query runs for much longer than I expect it to run for, and I
On 09/10/2013 12:57, Jesse Long wrote:
On 09/10/2013 12:10, Albe Laurenz wrote:
Jesse Long wrote:
I have the following query, run immediately after executing VACUUM in
the database. There is only one connection to the database.
You should run ANALYZE, not VACUUM.
The query runs for much