On Wed, 2021-02-03 at 10:54 +0100, Karsten Hilbert wrote:
> > I just ran a few practical tests on large (~14mil rows) tables that have
> > multiple indexes.
> > SELECT COUNT(id) forces PostgreSQL to use the primary key index.
> > SELECT COUNT(*) allows PostgreSQL to chose an index to use and it see
Am Wed, Feb 03, 2021 at 01:43:14AM -0500 schrieb Cherio:
> I just ran a few practical tests on large (~14mil rows) tables that have
> multiple indexes.
>
> SELECT COUNT(id) forces PostgreSQL to use the primary key index.
> SELECT COUNT(*) allows PostgreSQL to chose an index to use and it seems to
I just ran a few practical tests on large (~14mil rows) tables that have
multiple indexes.
SELECT COUNT(id) forces PostgreSQL to use the primary key index.
SELECT COUNT(*) allows PostgreSQL to chose an index to use and it seems to
be choosing one of smaller size which leads to less IO and hence re
Hello list
My English is not very good, so I pretend that through the examples you
understand what I intend to expose
-- Recreate the query that is supposedly wrong
select calendar.entry, count(*)
from generate_series('2020-08-20'::date, '2020-09-15'::date, '1
day'::interval) as calendar(entry)
On Mon, 2021-02-01 at 19:14 -0600, Matt Zagrabelny wrote:
> > > What is count(*) counting then? I thought it was rows.
> >
> > Yeah, but count(id) only counts rows where id isn't null.
>
> I guess I'm still not understanding it...
>
> I don't have any rows where id is null:
Then the *result* of
On Mon, Feb 1, 2021 at 7:19 PM Guillaume Lelarge
wrote:
>
>
> You're doing a left join, so I guess there's no row where
> call_records.timestamp::date = 2020-08-30. That would result with a NULL id.
>
>
Thanks for the excellent analysis everyone. I appreciate it!
Here is the documentation (for a
Le mar. 2 févr. 2021 à 02:14, Matt Zagrabelny a écrit :
>
>
> On Mon, Feb 1, 2021 at 6:35 PM Tom Lane wrote:
>
>> Matt Zagrabelny writes:
>> > On Mon, Feb 1, 2021 at 5:57 PM Rob Sargent
>> wrote:
>> >> You got one null from count(*) likely.
>>
>> > What is count(*) counting then? I thought it
At 2021-02-01T20:14:04-05:00, Matt Zagrabelny sent:
> select count(id) from call_records where id is null;
> count
> ═══
> 0
> (1 row)
>
> Time: 0.673 ms
>
> Which field is count(*) counting if it is counting nulls?
>
> -m
What you're overlooking is that, at least to my reading of y
On Mon, Feb 1, 2021 at 6:14 PM Matt Zagrabelny wrote:
> Which field is count(*) counting if it is counting nulls?
>
count(id) excludes from the count rows where the id field is null. The
presence of a left join in your query is introducing a null here due to
there not being a related field, not
On Mon, Feb 1, 2021 at 6:35 PM Tom Lane wrote:
> Matt Zagrabelny writes:
> > On Mon, Feb 1, 2021 at 5:57 PM Rob Sargent
> wrote:
> >> You got one null from count(*) likely.
>
> > What is count(*) counting then? I thought it was rows.
>
> Yeah, but count(id) only counts rows where id isn't null.
Matt Zagrabelny writes:
> On Mon, Feb 1, 2021 at 5:57 PM Rob Sargent wrote:
>> You got one null from count(*) likely.
> What is count(*) counting then? I thought it was rows.
Yeah, but count(id) only counts rows where id isn't null.
regards, tom lane
On Mon, Feb 1, 2021 at 5:57 PM Rob Sargent wrote:
[...]
>
> You got one null from count(*) likely.
>
What is count(*) counting then? I thought it was rows.
-m
On 2/1/21 4:53 PM, Matt Zagrabelny wrote:
Greetings,
Is there a preferred method of counting rows?
count(*) vs count(field_name)
I have used count(*) for a long time and am hitting an inconsistency. At
least it is an inconsistency to me (I'm sure there is an explanation)...
INCORRECT OUT
13 matches
Mail list logo
