>>On Tue, Nov 29, 2011 at 7:21 PM, Tyler Hains
wrote:
>> # explain analyze select * from cards where card_set_id=2850 order by
>> card_id limit 1;
>> QUERY
PLAN
>>
On Tue, Nov 29, 2011 at 7:21 PM, Tyler Hains wrote:
> # explain analyze select * from cards where card_set_id=2850 order by
> card_id limit 1;
> QUERY PLAN
> -
On 30.11.2011 23:22, Tyler Hains wrote:
>>> I haven't had a chance to experiment with the SET STATISTICS, but
> that
>>> got me going on something interesting...
>>>
>>> Do these statistics look right?
>>>
>>> # SELECT attname, n_distinct, most_common_vals, histogram_bounds FROM
>>> pg_stats WHERE
>> I haven't had a chance to experiment with the SET STATISTICS, but
that
>> got me going on something interesting...
>>
>> Do these statistics look right?
>>
>> # SELECT attname, n_distinct, most_common_vals, histogram_bounds FROM
>> pg_stats WHERE tablename = 'cards';
>>
>...
>> "card_set_id"
On 29.11.2011 23:19, Tomas Vondra wrote:
> Hi,
>
> what PostgreSQL version is this? That's the first thing we need to know.
>
> On 29.11.2011 22:28, Tyler Hains wrote:
>> Yes, I'm pretty sure autovacuum is enabled. Changing the query as shown
>> there uses the sub-optimal index.
>
> That doesn'
On 29.11.2011 22:43, Tyler Hains wrote:
> There are actually more like 27 million rows in the table. That's why it
> really should be filtering the rows using the index on the other column
> before ordering for the limit.
Well, the problem is that the PostgreSQL MVCC model is based on keeping
co
On 29.11.2011 23:06, Filip Rembiałkowski wrote:
> 2011/11/29 Tyler Hains :
>
>
>> I haven't had a chance to experiment with the SET STATISTICS, but that
>> got me going on something interesting...
>>
>> Do these statistics look right?
>>
>> # SELECT attname, n_distinct, most_common_vals, histogra
On 29.11.2011 21:34, Scott Marlowe wrote:
> On Tue, Nov 29, 2011 at 11:21 AM, Tyler Hains
> wrote:
>> # explain analyze select * from cards where card_set_id=2850 order by
>> card_id limit 1;
>>QUERY PLAN
>> -
Hi,
what PostgreSQL version is this? That's the first thing we need to know.
On 29.11.2011 22:28, Tyler Hains wrote:
> Yes, I'm pretty sure autovacuum is enabled. Changing the query as shown
> there uses the sub-optimal index.
That doesn't mean
> I haven't had a chance to experiment with the S
2011/11/29 Tyler Hains :
> I haven't had a chance to experiment with the SET STATISTICS, but that
> got me going on something interesting...
>
> Do these statistics look right?
>
> # SELECT attname, n_distinct, most_common_vals, histogram_bounds FROM
> pg_stats WHERE tablename = 'cards';
>
...
>
On Tue, Nov 29, 2011 at 11:21 AM, Tyler Hains
wrote:
> # explain analyze select * from cards where card_set_id=2850 order by
> card_id limit 1;
> QUERY
PLAN
>
2011/11/29 Tyler Hains :
> # explain analyze select * from cards where card_set_id=2850 order by
> card_id limit 1;
> QUERY
PLAN
>
--
On Tue, Nov 29, 2011 at 11:21 AM, Tyler Hains wrote:
> # explain analyze select * from cards where card_set_id=2850 order by
> card_id limit 1;
> QUERY PLAN
>
2011/11/29 Tyler Hains :
> # explain analyze select * from cards where card_set_id=2850 order by
> card_id limit 1;
> QUERY PLAN
> -
Hi,
We’ve got a strange situation where two queries get dramatically
different performance because of how the Query Optimizer handles LIMIT.
# explain analyze select * from cards where card_set_id=2850 order by
card_id;
QUERY
15 matches
Mail list logo
