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
Jesse Long wrote:
I did ALTER COLUMN SET STATISTICS 1 for each column involved after
that (is that what you meant?). But it did not make much difference, but
I have read the manual regarding this setting and think I understand it.
Would it be a bad idea to ALTER COLUMN SET STATISTICS
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 Fri, Oct 11, 2013 at 9:32 AM, Jesse Long j...@unknown.za.net wrote:
explain select * from archive_document_index where node_id = 29 and value
= 'BSH70002152';
QUERY PLAN
--**--**
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,
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 think
this is due to it using the
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
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.
Thanks you for the advise regarding
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 and 4 are seqscan, and they are
12 matches
Mail list logo
