Claudio Freire writes:
> Alternatively, a token startup cost could be added to those kinds of
> filtered sequential scans, when the filtering term is selective
> enough. That would offset the cost just a little bit, but enough to
> favor index over sequential on the right cases.
Maybe not so "tok
On Tue, Aug 6, 2013 at 3:46 AM, Ivan Voras wrote:
> Here are two more unexpected results. Same test table (1 mil. records,
> "id" is SERIAL PRIMARY KEY, PostgreSQL 9.1, VACUUM ANALYZE performed
> before the experiments):
>
> ivoras=# explain analyze select * from lt where id > 90 limit 10;
>
On Mon, Aug 5, 2013 at 6:54 PM, David Johnston wrote:
> Curious how much slower/faster these queries would run if you added:
>
> SELECT *, first_value(id) OVER (...), last_value(id) OVER (...)
> --note the window specifications need to overcome the "ORDER BY" limitation
> noted in the documentatio
On Tue, Aug 6, 2013 at 8:03 PM, Claudio Freire wrote:
> On Tue, Aug 6, 2013 at 7:56 PM, Mark Kirkwood
> wrote:
>> Hmm - I wonder if the lack or ORDER BY is part of the problem here. Consider
>> a similar query on pgbench_accounts:
>>
>> bench=# explain analyze select aid from pgbench_accounts whe
On Tue, Aug 6, 2013 at 7:56 PM, Mark Kirkwood
wrote:
> Hmm - I wonder if the lack or ORDER BY is part of the problem here. Consider
> a similar query on pgbench_accounts:
>
> bench=# explain analyze select aid from pgbench_accounts where aid > 10
> limit 20;
> QUERY PLAN
>
On 06/08/13 22:46, Ivan Voras wrote:
Here are two more unexpected results. Same test table (1 mil. records,
"id" is SERIAL PRIMARY KEY, PostgreSQL 9.1, VACUUM ANALYZE performed
before the experiments):
ivoras=# explain analyze select * from lt where id > 90 limit 10;
On Fri, Aug 2, 2013 at 3:27 PM, Scott Marlowe wrote:
> On Fri, Aug 2, 2013 at 2:51 PM, Tom Lane wrote:
>> Scott Marlowe writes:
>>> Yep. Added the indexes and performance went right into the dumper. New
>>> plan on new table with old data added in random order now looks like
>>> the old table, o
Hello
please, send result of EXPLAIN ANALYZE
please, use a http://explain.depesz.com/ for saving a plan
there is a more than 8 joins - so try to set geqo_threshold to 16,
join_collapse_limit to 16, and from_collapse_limit to 16.
Regards
Pavel Stehule
2013/8/2 :
> Good day,
>
> I have a perfo
On Tue, Aug 6, 2013 at 3:04 AM, Ivan Voras wrote:
>
> ivoras=# explain analyze select * from lt order by id desc limit 10;
> QUERY
> PLAN
>
On Mon, Aug 5, 2013 at 9:22 PM, Josh Berkus wrote:
> Ivan,
>
> > Or, more generally, is there some set of circumstances under which the
> > catastrophic scenario will happen?
>
> Yes:
>
> SELECT * FROM table ORDER BY id DESC LIMIT 10 OFFSET 10
>
> This is the "high offset" problem, and affect
On Tue, Aug 6, 2013 at 7:46 AM, Ivan Voras wrote:
> ivoras=# explain analyze select * from lt where id > 90 limit 10;
>QUERY PLAN
> --
Here are two more unexpected results. Same test table (1 mil. records,
"id" is SERIAL PRIMARY KEY, PostgreSQL 9.1, VACUUM ANALYZE performed
before the experiments):
ivoras=# explain analyze select * from lt where id > 90 limit 10;
QUERY PLAN
-
On 6 August 2013 02:20, Michael Paquier wrote:
>
> On Tue, Aug 6, 2013 at 8:25 AM, Claudio Freire
> wrote:
>>
>> On Mon, Aug 5, 2013 at 8:04 PM, Ivan Voras wrote:
>> > SELECT * FROM table ORDER BY id DESC LIMIT 10 OFFSET 10
>> >
>> > SELECT * FROM table WHERE active ORDER BY id DESC LIMIT 10 OFF
13 matches
Mail list logo
