Hello everyone,
I'm looking for a way to specify join order in SQL query. Actually, the
optimizer has chosen a plan with hash join of 2 tables, but I would like
to know if there is a way to force it to use hash join, but with replaced
tables on build phase and probe phase?
Thank you,
Mirko Spasic
Hi
I'm just trying about PostgreSQL, I create a database "test" with a table
"t1":
test=> \d t1
Table "public.t1"
Column | Type | Modifiers
-+-+-
col_id | integer | not null
jacket41142 wrote:
> [ subject issue in detail ]
Please review this thread:
http://www.postgresql.org/message-id/flat/CAPNY-2Utce-c+kNTwsMCbAk58=9myeaevitxt9lo7r1k77j...@mail.gmail.com#CAPNY-2Utce-c+kNTwsMCbAk58=9myeaevitxt9lo7r1k77j...@mail.gmail.com
--
Kevin Grittner
EDB: http://www.enterpri
On Tue, Dec 10, 2013 at 9:28 AM, jacket41142 wrote:
>
> test=> select distinct col_int from t1 group by col_int;
> Time: 1177.936 ms
>
> So the performance difference is not very large.
> But when I do that:
>
> test=> select count(distinct col_int) from t1;
> count
> ---
> 1025
> (1 row)
On Wed, Nov 27, 2013 at 2:28 AM, Metin Doslu wrote:
> We have several independent tables on a multi-core machine serving Select
> queries. These tables fit into memory; and each Select queries goes over one
> table's pages sequentially. In this experiment, there are no indexes or
> table joins.
>
On Tue, Dec 10, 2013 at 5:03 PM, Merlin Moncure wrote:
> Also, can I see a typical 'top' during poor scaling count(*) activity?
> In particular, what's sys cpu%. I'm guessing it's non trivial.
There was another thread, this seems like a mistaken double post or
something like that.
In that othe
On Tue, Dec 10, 2013 at 2:06 PM, Claudio Freire wrote:
> On Tue, Dec 10, 2013 at 5:03 PM, Merlin Moncure wrote:
>> Also, can I see a typical 'top' during poor scaling count(*) activity?
>> In particular, what's sys cpu%. I'm guessing it's non trivial.
>
>
> There was another thread, this seems l
On Thu, Dec 5, 2013 at 09:22:14AM -0500, Tom Lane wrote:
> salah jubeh writes:
> > When I excute a query,� the exection time is about 1 minute; however, when
> > I execute the query with explain analyze the excution time jumps to 10
> > minutes.
>
> This isn't exactly unheard of, although it
>>>On Thu, Dec 5, 2013 at 09:22:14AM -0500, Tom Lane wrote:
>>> salah jubeh writes:
>>> When I excute a query,�the exection time is about 1 minute;
however, when I execute the query with explain analyze the excution time
jumps to 10 minutes.
>>
>> This isn't exactly unheard of, although it
On Tue, Dec 10, 2013 at 01:53:54PM -0800, salah jubeh wrote:
> Thanks for the link, I find it very useful, unfortunatly I am using 9.1.11
> version.
>
> After digging a little bit, I find out that the gettimeofday is indeed a
> little
> bit slower on this particular machine than other machines,
Thanks very much.
I think another problem is that the cost estimation isn't good enough to
reflex real cost. Since we can see, from "explain analyze ...",
count(distinct ...) has smallest cost between the others, but since it uses
sorts, the time complexity should be higher especially for large am
I have done another experiment for count(*) vs count(distinct ...), on same
table schema but with 1000 rows now. And for this time, the postgres
version is 9.3.2 (9.3.2-1.pgdg12.4+1).
These two has same resulted query plan with same estimated cost, but
count(*) is straightly fast.
test=> expla
On Tuesday, December 10, 2013, jacket41142 wrote:
> Thanks very much.
>
> I think another problem is that the cost estimation isn't good enough to
> reflex real cost. Since we can see, from "explain analyze ...",
> count(distinct ...) has smallest cost between the others, but since it uses
> sorts
Hi
I'm just trying about PostgreSQL, I create a database "test" with a table
"t1":
test=> \d t1
Table "public.t1"
Column | Type | Modifiers
-+-+-
col_id | integer | not null
Hi,
my sql is very simple,
returns one row,
where conditions are assigned to primary keys
*/select g.gd_index, gd.full_name/**/
/**/from gd g join gd_data gd on (g.id_gd = gd.id_gd)/**/
/**/where gd.id_gd_data = OR g.id_gd = ;/*
but generates "crazy" plan with Merge Join on big amoun
I am trying to debug some shared memory issues with Postgres 9.3.1 and
CentOS release 6.3 (Final). I have a database machine that probably has
some misconfigured shared memory settings. It's getting into 2+ GB of
swap. Restarting postgres frees all of the memory, but after a few hours
of normal
Mack Talcott writes:
> I am trying to debug some shared memory issues with Postgres 9.3.1 and
> CentOS release 6.3 (Final). I have a database machine that probably has
> some misconfigured shared memory settings. It's getting into 2+ GB of
> swap. Restarting postgres frees all of the memory, bu
Krzysztof Olszewski wrote
> Hi,
>
> my sql is very simple,
> returns one row,
> where conditions are assigned to primary keys
>
>
> */select g.gd_index, gd.full_name/**/
> /**/from gd g join gd_data gd on (g.id_gd = gd.id_gd)/**/
> /**/where gd.id_gd_data = OR g.id_gd = ;/*
>
>
> but
18 matches
Mail list logo
