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
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
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
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
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
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
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
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,
>>>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 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 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 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 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)
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
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
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
18 matches
Mail list logo
