>>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
Jack Orenstein wrote:
If x is an integer column with an index, then
select ...
from T
where x > 1
and
select ...
from T
where x > 10
could be optimized differently. So how is optimization done for a
prepared statement containing a variable, e.g.
select .
>
> select ...
> from T
> where x > $1
>
prepare testy_prepare(int) as select * from T where x = $1;
execute testy_prepare(4);
Follow the docs :)
http://www.postgresql.org/docs/8.1/interactive/sql-prepare.html
--
Emanuel Calvo Franco
ArPUG [www.arpug.com.ar] / AOSUG Mem
If x is an integer column with an index, then
select ...
from T
where x > 1
and
select ...
from T
where x > 10
could be optimized differently. So how is optimization done for a prepared
statement containing a variable, e.g.
select ...
from T
where
On Saturday 21 July 2007 Tom Lane's cat, walking on the keyboard, wrote:
> Beyond that, the GEQO chapter provides several references, and IMHO
> you should not be all that resistant to looking into the source code.
> Even if you don't read C well, many of the files provide a wealth of
> info in the
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> On Thu, Jul 19, 2007 at 10:41:03AM -0400, Tom Lane wrote:
>>> The developers section of the website used to have slides from a couple
>>> of talks I gave at OSCON, but I don't see them there anymore :-(
>
>> How long ago was this (th
Luca Ferrari <[EMAIL PROTECTED]> writes:
>> src/backend/optimizer/README
> I've read this yesterday, very interesting, but I'm looking for something
> similar related to geqo. I mean, is there any presentation/demo that
> step-y-step explains how geqo could take decisions?
There's not a lot, bu
On Thursday 19 July 2007 Tom Lane's cat, walking on the keyboard, wrote:
> http://developer.postgresql.org/pgdocs/postgres/overview.html
> (particularly 42.5)
I have already read this, thanks.
>
> src/backend/optimizer/README
I've read this yesterday, very interesting, but I'm looking for someth
Magnus Hagander wrote:
> On Thu, Jul 19, 2007 at 10:41:03AM -0400, Tom Lane wrote:
> > The developers section of the website used to have slides from a couple
> > of talks I gave at OSCON, but I don't see them there anymore :-(
>
> How long ago was this (that they were on the website)? I don't re
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Thu, Jul 19, 2007 at 10:41:03AM -0400, Tom Lane wrote:
>> The developers section of the website used to have slides from a couple
>> of talks I gave at OSCON, but I don't see them there anymore :-(
> How long ago was this (that they were on the webs
On Thu, Jul 19, 2007 at 10:41:03AM -0400, Tom Lane wrote:
> Luca Ferrari <[EMAIL PROTECTED]> writes:
> > I'd like to better understand how the optimizer works and is implemented.
> > Is
> > there any available documentation (before start reading the source!) to
> > understand concepts about geqo
On Thu, 19 Jul 2007, Tom Lane wrote:
The developers section of the website used to have slides from a couple
of talks I gave at OSCON, but I don't see them there anymore :-(
This one is still around:
http://conferences.oreillynet.com/presentations/os2003/lane_tom.pdf
I'd also recommend http:/
Luca Ferrari <[EMAIL PROTECTED]> writes:
> I'd like to better understand how the optimizer works and is implemented. Is
> there any available documentation (before start reading the source!) to
> understand concepts about geqo and system r? Any chance about any demo or
> presentation with detail
On Tuesday 17 April 2007 Tom Lane's cat, walking on the keyboard, wrote:
> "jungmin shin" <[EMAIL PROTECTED]> writes:
> > As I see the documentation of postgres, postgres use genetic algorithm
> > for query optimization rather than system R optimizer. right?
>
> Only for queries with more than geqo
"jungmin shin" <[EMAIL PROTECTED]> writes:
> As I see the documentation of postgres, postgres use genetic algorithm for
> query optimization rather than system R optimizer. right?
Only for queries with more than geqo_threshold relations. The join
search algorithm for smaller queries is a System-R
Hello,
As I see the documentation of postgres, postgres use genetic algorithm for
query optimization rather than system R optimizer. right?
--
Jungmin Shin
You can use EXPLAIN and EXPLAIN ANALYZEFor details please have a look at --> http://www.postgresql.org/docs/8.1/interactive/performance-tips.html
/ShoaibOn 6/16/06, shyju c.k <[EMAIL PROTECTED]> wrote:
hai all
plz send gen info abt query optimizer technic in postgresql
with example
orgSubject: [GENERAL]
query optimizer
hai all
plz send gen info abt query optimizer technic in
postgresql
with example
hai all
plz send gen info abt query optimizer technic in postgresql
with example
Robert Berger <[EMAIL PROTECTED]> writes:
> Why do the following three queries use different scan types under 7.1.2?
As Peter points out, index optimization of LIKE queries is disabled
unless your database is in C locale (if you're not sure,
contrib/pg_controldata can tell you what locale your da
Thanks. How do I set the locale?
> In 7.1, LIKE optimization (i.e., possibly using an index) has been
> disabled unless you are in the C locale because it does not work
> correctly. You could set your locale to C and re-initdb to get it to work
> again.
>
> --
> Peter Eisentraut [EMAIL PROTEC
Why do the following three queries use different scan types under 7.1.2?
Under
6.5.3 they all used index (and my system ran MUCH faster, since I often
use the trailing %)
I've done a vacuum analyze.
I installed 7.1.2 on RedHat 6.2 using the RPMs.
anderson=# explain select value from s_n_grantor
36 matches
Mail list logo
