Dear Jeff,
Thanks for your help,
* The reindex solution doesn't work. I just tried it, and
the query planner
is still using the wrong indexes.
It switched to a better one of the wrong indices, though, and got
several times faster.
I think that this is a
Dear Tom,
Thanks very much for your advice.
A psql session is below. This shows that, if I force the planner to use
the partial index, by dropping the others, then it's fast. But as soon
as I put the full indexes back (which I need for other queries), the
query planner chooses them instead, an
On Wednesday, December 19, 2012, Richard Neill wrote:
> Thanks for your help,
>
> On 20/12/12 00:08, Sergey Konoplev wrote:
>
>> On Wed, Dec 19, 2012 at 3:49 PM, Richard Neill
>> wrote:
>>
>>> * The reindex solution doesn't work. I just tried it, and the query
>>> planner
>>> is still using the w
Richard Neill writes:
> The problem is, when I now run my query, the planner ignores the
> dedicated index "tbl_tracker_performance_1_idx", and instead uses both
> of the full indexes... resulting in a much much slower query (9ms vs
> 0.08ms).
> A psql session is below. This shows that, if I
Frankly, at 12 microseconds per matched pair of rows, I think
> you're doing OK.
>
> This plan is the good one, I want the indexscan nested loop join and this
is only achieved after making all these costing factors change. Before
that, it was hash join and was very slow.
However, I'm worried about
Thanks for your help,
On 20/12/12 00:08, Sergey Konoplev wrote:
On Wed, Dec 19, 2012 at 3:49 PM, Richard Neill wrote:
* The reindex solution doesn't work. I just tried it, and the query planner
is still using the wrong indexes.
Can you show the explain analyze with tbl_tracker_performance_1_
On Wed, Dec 19, 2012 at 3:49 PM, Richard Neill wrote:
> * The reindex solution doesn't work. I just tried it, and the query planner
> is still using the wrong indexes.
Can you show the explain analyze with tbl_tracker_performance_1_idx
straight after reindex (eg. before it has been bloated again)
On 19/12/12 22:59, Sergey Konoplev wrote:
On Wed, Dec 19, 2012 at 1:13 PM, Richard Neill wrote:
Index Scan using tbl_tracker_performance_1_idx on tbl_tracker
(cost=0.00..5440.83 rows=1 width=174) (actual time=0.052..0.052 rows=0
loops=1)
Index Cond: (parcel_id_code = 53030)
It looks
Hi,
On Wed, Dec 19, 2012 at 1:13 PM, Richard Neill wrote:
> Index Scan using tbl_tracker_performance_1_idx on tbl_tracker
> (cost=0.00..5440.83 rows=1 width=174) (actual time=0.052..0.052 rows=0
> loops=1)
>Index Cond: (parcel_id_code = 53030)
It looks like your index is bloated. Have you h
Dear All,
I've just joined this list, and I'd like to request some advice.
I have a table (1 GB in size) with 24 columns, and 5.6 million rows. Of
these, we're interested in two columns, parcel_id_code, and exit_state.
parcel_id_code has a fairly uniform distribution of integers
Trying again since I couldn't post without being subscribed. The message
got stalled and was never sent, so I just subscribed and I'm trying
again. Original message I tried to send two days ago:
--
I've explained a bit of how my application works in this thread
> -Original Message-
> From: Vibhor Kumar [mailto:vibhor.ku...@enterprisedb.com]
> Sent: Monday, December 17, 2012 11:34 AM
> To: suhas.basavaraj12
> Cc: pgsql-performance@postgresql.org
> Subject: Re: How can i find out top high load sql queries in
> PostgreSQL.
>
>
> On Dec 17, 2012, at
"Huan Ruan" wrote:
> explain (analyze, buffers)
> SELECT
> *
> FROM IM_Match_Table smalltable
> inner join invtran bigtable on bigtable.invtranref = smalltable.invtranref
Well, one table or the other will need to be read in full, and you
would normally want that one to be the small table. When
13 matches
Mail list logo
