On Thu, Dec 9, 2010 at 11:56 AM, Dimitri Fontaine
wrote:
> Merlin Moncure writes:
>> On Wed, Dec 8, 2010 at 8:57 AM, Tatsuo Ishii wrote:
>>>
>>> Then execute the huge SELECT:
>>> http://codezine.jp/static/images/article/1629/html/sql.html
>>
>> benchmark what you've got against this (ported to p
Merlin Moncure writes:
> On Wed, Dec 8, 2010 at 8:57 AM, Tatsuo Ishii wrote:
>>
>> Then execute the huge SELECT:
>> http://codezine.jp/static/images/article/1629/html/sql.html
>
> benchmark what you've got against this (ported to postgres by marcin mank):
> http://www.pastie.org/684163
It that t
Excerpts from Jan Urbański's message of mié dic 08 17:11:44 -0300 2010:
> I'm pleasantly surprised that the SA code as it stands today, setting
> the equlibrium factor to 8 and temperature reduction factor to 0.4, the
> query takes 1799.662 ms in total.
That's 5x better than Oracle :-)
--
Álvar
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> On 08/12/10 21:18, Tom Lane wrote:
>> Hmmm ... "runs forever" is a bit scary.
> With SA you start with a temperature that's linearily dependant on the
> size of the query, and back off exponentially. Each step means work tha
> also depends on the size of
On 08/12/10 21:18, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> I'm pleasantly surprised that the SA code as it stands today, setting
>> the equlibrium factor to 8 and temperature reduction factor to 0.4, the
>> query takes 1799.662 ms in total.
>
> Cool.
>
>> With the default v
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> I'm pleasantly surprised that the SA code as it stands today, setting
> the equlibrium factor to 8 and temperature reduction factor to 0.4, the
> query takes 1799.662 ms in total.
Cool.
> With the default values it runs
> forever, but I long discovered
On 08/12/10 19:02, Jan Urbański wrote:
> On 08/12/10 18:45, Tom Lane wrote:
>> The real fix in my mind is to replace GEQO search with something
>> smarter. I wonder what happened to the SA patch that was reported
>> on at PGCon.
>
> I got distracted with other things :( I'll try to plan the two q
On 08/12/10 18:45, Tom Lane wrote:
> The real fix in my mind is to replace GEQO search with something
> smarter. I wonder what happened to the SA patch that was reported
> on at PGCon.
I got distracted with other things :( I'll try to plan the two queries
with SA and see what the results are. If
I wrote:
> There is something funny going on there; it's not just that the planner
> is slower with a large flat search space. It is slower, but only maybe
> 5x or so. What I'm seeing is that it actually finds a much worse plan
> (very much larger estimated cost as well as actual runtime) when gi
Robert Haas writes:
> On Wed, Dec 8, 2010 at 8:57 AM, Tatsuo Ishii wrote:
>> In the page first one takes infinite time by PostgreSQL 9.0.1. Next
>> one can be executed very quickly because the join order is explicitely
>> specified by cross join syntax. This seems to be a limitation of
>> Postgr
On Wed, Dec 8, 2010 at 8:57 AM, Tatsuo Ishii wrote:
> In the page first one takes infinite time by PostgreSQL 9.0.1. Next
> one can be executed very quickly because the join order is explicitely
> specified by cross join syntax. This seems to be a limitation of
> PostgreSQL optimizer and I would
On Wed, Dec 8, 2010 at 8:57 AM, Tatsuo Ishii wrote:
> Hi,
>
> I found an interesting article which explains how to solve "sudoku" by
> using SQL(unfortunately written in Japanese):
> http://codezine.jp/article/detail/1629?p=2
>
> In the article example sudoku is:
> http://static.shoeisha.jp/cz/sta
Hi,
I found an interesting article which explains how to solve "sudoku" by
using SQL(unfortunately written in Japanese):
http://codezine.jp/article/detail/1629?p=2
In the article example sudoku is:
http://static.shoeisha.jp/cz/static/images/article/1629/problem4.gif
To solve the example you crea
13 matches
Mail list logo
