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 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
>
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
On Wed, Jun 1, 2011 at 6:28 PM, CS DBA wrote:
> On 06/01/2011 03:38 PM, Kevin Grittner wrote:
>>
>> CS DBA wrote:
>>
>>> The app wants to run a query like this:
>>>
>>> select count(pri_num) from max_xtrv_st_t
>>> where pri_num in (select max(pri_num) from max_xtrv_st_t where 1=1
>>>
On 06/01/2011 03:15 PM, Merlin Moncure wrote:
On Wed, Jun 1, 2011 at 3:14 PM, CS DBA wrote:
Hi All;
We have a table with approx 200 columns. about a dozen columns are text data
types and the rest are a mix of integers , bigint's and double precision
types.
The table has about 25million rows.
On 06/01/2011 03:38 PM, Kevin Grittner wrote:
CS DBA wrote:
The app wants to run a query like this:
select count(pri_num) from max_xtrv_st_t
where pri_num in (select max(pri_num) from max_xtrv_st_t where 1=1
group by tds_cx_ind, cxs_ind_2)
Why not something
CS DBA wrote:
> The app wants to run a query like this:
>
> select count(pri_num) from max_xtrv_st_t
> where pri_num in (select max(pri_num) from max_xtrv_st_t where 1=1
> group by tds_cx_ind, cxs_ind_2)
Why not something simpler? There are a number of possibi
On Wed, Jun 1, 2011 at 3:14 PM, CS DBA wrote:
> Hi All;
>
> We have a table with approx 200 columns. about a dozen columns are text data
> types and the rest are a mix of integers , bigint's and double precision
> types.
>
> The table has about 25million rows.
>
>
> The app wants to run a query li
Hi All;
We have a table with approx 200 columns. about a dozen columns are text
data types and the rest are a mix of integers , bigint's and double
precision types.
The table has about 25million rows.
The app wants to run a query like this:
select count(pri_num) from max_xtrv_st_t
where pr
Dan Libby <[EMAIL PROTECTED]> writes:
> Or failing that, I'd at least like to understand why the planner
> is deciding not to use the category_lang index when the result
> set is coming from a function instead of a "regular" table.
The planner defaults to assuming that set-returning functions re
Hi,
Using postgres 8.0.1, I'm having a problem where a user-defined function
that executes quite quickly on its own slows down the calling query,
which ignores at least one index. I don't think this should be happening.
Please forgive the long explanation below; I'm trying to be clear.
So --
15 matches
Mail list logo
