"David G. Johnston" writes:
> So just use “offset 5_000_000 limit 1”. Bringing in a window function here
> seems unhelpful.
Yeah, that. A bite-size example might help clarify what the window
function is doing:
regression=# create table zed(f1 int) ;
CREATE TABLE
regression=# insert into zed se
On Monday, November 4, 2024, Guyren Howe wrote:
> I’m trying to get the id of the 5,000,000th record, so I can join against
> it to get a name. I didn’t fully understand what the docs say there. What
> am I missing?
>
So just use “offset 5_000_000 limit 1”. Bringing in a window function here
se
On Monday, November 4, 2024, Guyren Howe wrote:
> Wouldn’t it be offset 4_999_999?
>
Probably. I tend to expect off-by-one for these kinds of things and test
my way out.
>
> I’d still like to understand why nth_value doesn’t work.
>
When you perform an order by in a window clause the frame y
Wouldn’t it be offset 4_999_999?
I’d still like to understand why nth_value doesn’t work.
On 4 Nov 2024 at 15:44 -0800, David G. Johnston ,
wrote:
> On Monday, November 4, 2024, Guyren Howe wrote:
> > I’m trying to get the id of the 5,000,000th record, so I can join against
> > it to get a name
I’m trying to get the id of the 5,000,000th record, so I can join against it to
get a name. I didn’t fully understand what the docs say there. What am I
missing?
On 4 Nov 2024 at 15:36 -0800, Erik Wienhold , wrote:
> On 2024-11-05 00:17 +0100, Guyren Howe wrote:
> > This query:
> >
> > SELECT NTH
On 2024-11-05 00:17 +0100, Guyren Howe wrote:
> This query:
>
> SELECT NTH_VALUE(id, 500) OVER (ORDER BY created_at, id ASC) FROM table
>
> in a table where SELECT COUNT(*) returns a value a few thousand over 5
> million, where id is the primary key, returns null.
>
> The inclusion of the pr
On 11/4/24 15:17, Guyren Howe wrote:
This query:
SELECT NTH_VALUE(id, 500) OVER (ORDER BY created_at, id ASC) FROM table
in a table where SELECT COUNT(*) returns a value a few thousand over 5
million, where id is the primary key, returns null.
The inclusion of the primary key should make
This query:
SELECT NTH_VALUE(id, 500) OVER (ORDER BY created_at, id ASC) FROM table
in a table where SELECT COUNT(*) returns a value a few thousand over 5 million,
where id is the primary key, returns null.
The inclusion of the primary key should make the order by a total order. So
there s
On 2024-11-04 14:35:23 +0100, Costa Alexoglou wrote:
> > I don't know if Docker does anything strange here.
>
> I am not sure if this is docker specific or cgroup comes into play.
> The measurement is implemented in docker CLI, but I would make the
> assumption that the eviction is done within th
On 11/4/24 12:02, Jim Rosenberg wrote:
Is it considered bad Postgresql practice to have a column name that begins
with the underscore character ("_")?
I'm not sure where this is documented, but I'm seeing that Postgresql
accepts prepending an underscore to a data type name as a kind of alias for
Jim Rosenberg writes:
> Is it considered bad Postgresql practice to have a column name that begins
> with the underscore character ("_")?
I wouldn't say so.
> I'm not sure where this is documented, but I'm seeing that Postgresql
> accepts prepending an underscore to a data type name as a kind of
Is it considered bad Postgresql practice to have a column name that begins
with the underscore character ("_")?
I'm not sure where this is documented, but I'm seeing that Postgresql
accepts prepending an underscore to a data type name as a kind of alias for
appending [] to define an array data typ
David Rowley writes:
> On Mon, 4 Nov 2024 at 22:52, ma lz wrote:
>> select distinct a from t1 intersect select distinct a from t1;— this is
>> faster than origin sql
> No, the planner does not attempt that optimisation. INTERSECT really
> isn't very well optimised.
It's not really obvious
> I don't know if Docker does anything strange here.
I am not sure if this is docker specific or cgroup comes into play.
The measurement is implemented in docker CLI, but I would make the
assumption
that the eviction is done within the cgroup scope.
> A large file (or many smaller files) which is
On Mon, 4 Nov 2024 at 22:52, ma lz wrote:
>
> some sql like ' select a from t1 intersect select a from t1 '
>
> if t1 has large number rows but has few distinct rows
>
> select distinct a from t1 intersect select distinct a from t1;— this is
> faster than origin sql
>
> can postgres do this o
some sql like ' select a from t1 intersect select a from t1 '
if t1 has large number rows but has few distinct rows
select distinct a from t1 intersect select distinct a from t1;― this is
faster than origin sql
can postgres do this optimize during plan-queries?
16 matches
Mail list logo
