On Thu, Jun 2, 2011 at 2:56 PM, Claudio Freire wrote:
> On Thu, Jun 2, 2011 at 4:57 PM, Kevin Grittner
> wrote:
>> And the
>> planner does take the size of work_mem and the expected data set
>> into consideration when estimating the cost of the hash join.
>
> And shouldn't it?
>
> In a gross mode
On 06/02/2011 11:31 AM, Shaun Thomas wrote:
On 06/02/2011 11:15 AM, Kevin Grittner wrote:
They all gave the same result, of course, and they all used a seq
scan..
And they all will. I created a test table with a bunch of
generate_series and emulated 200 unique matches of column1 and
column2
Shaun Thomas wrote:
> On 06/02/2011 11:15 AM, Kevin Grittner wrote:
>
>> They all gave the same result, of course, and they all used a seq
>> scan..
>
> And they all will.
I always eschew generalizations, since they're always wrong. ;-) I
used a real table which had somewhat similar indexes to
On Wed, Jun 1, 2011 at 8:10 PM, Robert James wrote:
> A query I has spends a long time on Hash Joins (and Hash Left Joins).
> I have a few questions:
>
> 1. When does Postgres decide to do a Hash Join, over another type of Join?
> 2. Do Hash Joins normally perform poorly? What can I do to speed t
On Thu, Jun 2, 2011 at 4:57 PM, Kevin Grittner
wrote:
> And the
> planner does take the size of work_mem and the expected data set
> into consideration when estimating the cost of the hash join.
And shouldn't it?
In a gross mode, when hash joins go to disk, they perform very poorly.
Maybe the pl
On 06/02/2011 11:15 AM, Kevin Grittner wrote:
They all gave the same result, of course, and they all used a seq
scan..
And they all will. I created a test table with a bunch of
generate_series and emulated 200 unique matches of column1 and column2,
on a table with a mere 1-million rows (5000
"Kevin Grittner" wrote:
> Shaun Thomas wrote:
>> What you really want is this:
>>
>> SELECT count(1) FROM (
>>SELECT DISTINCT tds_cx_ind, cxs_ind_2
>> FROM max_xtrv_st_t
>> );
>
> Or maybe:
>
> SELECT count(DISTINCT (tds_cx_ind, cxs_ind_2)) FROM max_xtrv_st_t;
Or maybe not. I t
On 06/02/2011 08:47 AM, Kevin Grittner wrote:
Is there some reason to believe that a sequential scan isn't the
fastest way to get the data? When generating summary data like
this, it often is faster than lots of random access. If you can
coerce it into a faster plan by turning off enable_seqsc
Shaun Thomas wrote:
> You're counting the number of maximum values in your table for
> tds_cx_ind and cxs_ind_2, but there will always be at least one
> for every combination.
Good point.
> What you really want is this:
>
> SELECT count(1) FROM (
>SELECT DISTINCT tds_cx_ind, cxs_ind_2
>
Robert James wrote:
> A query I has spends a long time on Hash Joins (and Hash Left
> Joins).
To submit a post which gives us enough information to help you speed
up that query, please read this page:
http://wiki.postgresql.org/wiki/SlowQueryQuestions
> I have a few questions:
>
> 1. When
CS DBA wrote:
> On 06/01/2011 03:38 PM, Kevin Grittner wrote:
>> select count(*) from
>>(select distinct max(pri_num)
>>from max_xtrv_st_t
>>group by tds_cx_ind, cxs_ind_2) x
> I've tried a number of alternates, each one wants to do a seq scan
> of the table (including your suggest
Hi Jeff,
Thanks for the help.
This is the first post by me, and I did mistake unknowingly. I will
take care of it next time.
Again thanks a lot for the help.
--
Thanks & regards,
JENISH VYAS
On Thu, Jun 2, 2011 at 10:04 AM, Jeff Davis wrote:
>
> In the future, please remember to CC the list
Hi, Merlin. You wrote:
select string_agg(v, '') from (select
ascii(regexp_split_to_table('abc', $$\s*$$))::text as v) q;
Wow. I've been programming with pl/pgsql for a good number of years,
but only now do I see the amazing usefulness of regexp_split_to_table
and string_agg, neither of whic
13 matches
Mail list logo
