On Sat, May 29, 2021, 4:40 AM Lionel Bouton wrote:
> The last time I had to use this setting to solve this kind of problem I
> ended with :
>
> default_statistics_target = 500
>
> But obviously the value suited to your case could be different (I'd
> increase it until the planner uses the correct
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Saturday, 29 May 2021 17:55, Tom Lane wrote:
> Michael Nolan htf...@gmail.com writes:
>
> > You probably need some kind order by case when else end clause,
> > where the else clause deals with the non-VIPs, prob
Michael Nolan writes:
> You probably need some kind order by case when else end clause,
> where the else clause deals with the non-VIPs, probably negating the need
> for a nulls last clause.
The idiomatic way to do this, assuming that you create an "is_vip bool"
field or some other way
On Sat, May 29, 2021 at 9:15 AM Laura Smith <
n5d9xq3ti233xiyif...@protonmail.ch> wrote:
> Hi
>
> I've got a bit of a puzzle that I'm not quite sure how to approach.
>
> Let's say I've got a table of bios, so :
>
> create table bios (
> first_name text not null,
> last_name text not null,
> person
On 5/29/21 9:34 AM, Laura Smith wrote:
‐‐‐ Original Message ‐‐‐
On Saturday, 29 May 2021 17:06, Adrian Klaver wrote:
On 5/29/21 9:00 AM, Laura Smith wrote:
I did try "nulls last" but will give it another go, maybe I messed up on the
ordering of clauses.
Unless the fields you are
‐‐‐ Original Message ‐‐‐
On Saturday, 29 May 2021 17:06, Adrian Klaver wrote:
> On 5/29/21 9:00 AM, Laura Smith wrote:
>
> > I did try "nulls last" but will give it another go, maybe I messed up on
> > the ordering of clauses.
>
> Unless the fields you are ordering on contain NULLs I'm
On 5/28/21 5:38 PM, Dean Gibson (DB Administrator) wrote:
Did it run in less than 10 hours?
The original VACUUM FULL ANALYZE ran in 10 hours. The plain ANALYZE ran
in 88 seconds.
Can you repeat your EXPLAIN (ANALYZE, BUFFERS) of the query from your
first post and post them here:
http
On 5/29/21 9:00 AM, Laura Smith wrote:
I did try "nulls last" but will give it another go, maybe I messed up on the
ordering of clauses.
Unless the fields you are ordering on contain NULLs I'm not sure how
this is going to deal with your issue.
Sent with ProtonMail Secure Email.
‐‐‐
I did try "nulls last" but will give it another go, maybe I messed up on the
ordering of clauses.
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Saturday, 29 May 2021 15:23, Michael van der Kolff
wrote:
> Have you considered use of the "nulls last" option in order by
WAL can be built up for reasons like
1) if you have an inactive replication slot. I mean you had a streaming
replica which was turned off, but you did not remote the slot from primary.
2) Do you have archiving enabled? Are the archiving commands running fine ?
if just the archiving is broken, then
Have you considered use of the "nulls last" option in order by (
https://www.postgresql.org/docs/13/queries-order.html)?
Alternatively, you could write your own type, with its own ordering
primitive 😉
On Sun, 30 May 2021, 12:15 am Laura Smith, <
n5d9xq3ti233xiyif...@protonmail.ch> wrote:
> Hi
>
On Saturday, May 29, 2021, Laura Smith
wrote:
>
> The problem is that my use-case calls for a scenario where due to protocol
> certain people may be designated as "VIP" and therefore need to appear at
> the top. In addition, protocol may dictate that those "VIP" people
> themselves may (sometime
Hi
I've got a bit of a puzzle that I'm not quite sure how to approach.
Let's say I've got a table of bios, so :
create table bios (
first_name text not null,
last_name text not null,
person_title text,
person_short_bio text
);
Now, the "natural order" would be a standard "select * from bios ord
Yeah, indexes could slow things down, thanks. Btw I'm not using logical
replication for the upgrade, that's not supported for 9.3.
It was more complicated but that's beside the point.
I could just delete the publication and all that belongs to it and start
over. But since I'm trying out logical re
Le 29/05/2021 à 02:38, Dean Gibson (DB Administrator) a écrit :
> On 2021-05-28 16:51, Ron wrote:
>> On 5/28/21 5:06 PM, Dean Gibson (DB Administrator) wrote:
>>> On 2021-05-28 12:38, Ron wrote:
On 5/28/21 1:40 PM, Dean Gibson (DB Administrator) wrote:
> On 2021-05-28 08:12, Adrian Klaver
15 matches
Mail list logo
