Hi all. I'm excited about 9.4's new JSONB and search-performance. Is it
possible to combine tsearch's prefix-search with the new JSONB-format?
Something like this (pseudo-code): SELECT '{"subject": "visena"}'::jsonb @>
'{"subject": to_tsquery('simple', '(vise:*|office:*)')}'; and have t
Madhurima Das wrote:
> I am writing a C program to access a PostgreSQL database, where
> I add a column if it doesn't exists in the table
> or, update the column, if the column already exits.
> Please suggest how to work with the conditional statements.
> N.B. I wrote the following:
>
> res = PQe
Le 07/07/2014 12:48, Albe Laurenz a écrit :
Madhurima Das wrote:
I am writing a C program to access a PostgreSQL database, where
I add a column if it doesn't exists in the table
or, update the column, if the column already exits.
Please suggest how to work with the conditional statements.
N.B.
Le 07/07/2014 13:44, Pujol Mathieu a écrit :
Le 07/07/2014 12:48, Albe Laurenz a écrit :
Madhurima Das wrote:
I am writing a C program to access a PostgreSQL database, where
I add a column if it doesn't exists in the table
or, update the column, if the column already exits.
Please suggest ho
On 7/6/2014 10:47 PM, David G Johnston wrote:
madhu_d wrote
Hi,
I am writing a C program to access a PostgreSQL database, where
I add a column if it doesn't exists in the table
or, update the column, if the column already exits.
Please suggest how to work with the conditional statements.
Th
On 07/07/2014 11:28 AM, Andreas Joseph Krogh wrote:
> Hi all.
>
> I'm excited about 9.4's new JSONB and search-performance.
>
> Is it possible to combine tsearch's prefix-search with the new JSONB-format?
>
> Something like this (pseudo-code):
> SELECT '{"subject": "visena"}'::jsonb @> '{"su
På mandag 07. juli 2014 kl. 20:15:16, skrev Vik Fearing mailto:vik.fear...@dalibo.com>>: On 07/07/2014 11:28 AM, Andreas Joseph Krogh
wrote:
> Hi all.
>
> I'm excited about 9.4's new JSONB and search-performance.
>
> Is it possible to combine tsearch's prefix-search with the new JSONB-forma
Hello
We are using postgresql 8.3 database for last 5 yrs for this
production database and its running fine. This is our critical database
which runs 24*7. This weekend we started getting these messages
HINT: To avoid a database shutdown, execute a full-database VACUUM.
WARNING: database
Sounds like you just have to wait until it finishes..
On Mon, Jul 7, 2014 at 12:56 PM, Prabhjot Sheena <
prabhjot.she...@rivalwatch.com> wrote:
> Hello
>We are using postgresql 8.3 database for last 5 yrs for this
> production database and its running fine. This is our critical database
It does say a FULL vacuum, and that you are not doing.
Original message From: Mike Christensen
Date:07/07/2014 3:17 PM (GMT-06:00)
To: Prabhjot Sheena Cc:
pgsql-ad...@postgresql.org,Forums postgresql
Subject: Re: [ADMIN] [GENERAL] WARNING: database must be vacuumed
withi
Maybe you can priorize your worker with a ionice?
- Mail original -
De: "Mike Christensen"
À: "Prabhjot Sheena"
Cc: pgsql-ad...@postgresql.org, "Forums postgresql"
Envoyé: Lundi 7 Juillet 2014 16:15:18
Objet: Re: [ADMIN] [GENERAL] WARNING: database must be vacuumed within 8439472
tran
On Mon, 7 Jul 2014 15:22:44 -0500 (CDT) Scott Whitney wrote:
> It does say a FULL vacuum, and that you are not doing.
You're confusing terminology. VACUUM FULL is not the same as
a "full database vacuum". The latter is simply expressing that
vacuuming individual tables won't fix the problem.
That actually sounds terrifying. I'd throw up a caching layer ASAP to try
to decrease the speed those transactions are happening.
Frank
On Mon, Jul 7, 2014 at 2:25 PM, Nicolas Zin <
nicolas@savoirfairelinux.com> wrote:
> Maybe you can priorize your worker with a ionice?
>
> - Mail origi
Prabhjot Sheena wrote:
> Hello
>We are using postgresql 8.3 database for last 5 yrs for this
> production database and its running fine. This is our critical database
> which runs 24*7. This weekend we started getting these messages
>
> HINT: To avoid a database shutdown, execute a full-d
While the vacuumdb --analyze command is running i m getting these messages
for these tables which might require full vacuum.
WARNING: relation "public.result" contains more than "max_fsm_pages" pages
with useful free space
HINT: Consider using VACUUM FULL on this relation or increasing the
confi
Prabhjot Sheena wrote:
> While the vacuumdb --analyze command is running i m getting these messages
> for these tables which might require full vacuum.
>
> WARNING: relation "public.result" contains more than "max_fsm_pages" pages
> with useful free space
> HINT: Consider using VACUUM FULL on th
Yes. That's what I was referring to. Back in my 8.3 days, I was required to do
a FULL vacuum every week. I discussed it quite a bit on this list, and there
were many people who said it should not have been required, but it was, and it
resolved my particular issues (clogs not getting removed unti
i will run full vacuum than and see how it goes.
Thanks
avi
On Mon, Jul 7, 2014 at 2:05 PM, Scott Whitney wrote:
> Yes. That's what I was referring to. Back in my 8.3 days, I was required
> to do a FULL vacuum every week. I discussed it quite a bit on this list,
> and there were many people wh
On Mon, Jul 7, 2014 at 4:56 PM, Prabhjot Sheena <
prabhjot.she...@rivalwatch.com> wrote:
>We are using postgresql 8.3 database for last 5 yrs for this
> production database and its running fine.
>
Man. You really should consider upgrading to a more recent version. If you
are running "fine
Prabhjot Sheena writes:
> i will run full vacuum than and see how it goes.
I think that is seriously bad advice. It will take longer and not do
anything more to resolve your immediate problem --- which, it appears,
you don't have a whole lot of time to resolve if you want to avoid a
forced shutd
On 7/7/2014 2:14 PM, Prabhjot Sheena wrote:
i will run full vacuum than and see how it goes.
do make sure there aren't any OLD pending transactions hanging around.
if you have any stalled client connections that have left a transaction
open for weeks/months, vacuum can't free any tuples newe
John R Pierce writes:
> On 7/7/2014 2:14 PM, Prabhjot Sheena wrote:
>> i will run full vacuum than and see how it goes.
> do make sure there aren't any OLD pending transactions hanging around.
Not only regular transactions, but prepared transactions:
select * from pg_prepared_xacts;
8.3 was
On Sun, Jul 6, 2014 at 7:14 AM, Vik Fearing wrote:
> > NOT EXISTS translates to HASH ANTI JOIN and NOT IN translates to NOT
> > (HASHED) operation.
> >
> > Given that the columns used in NOT IN clause (for outer as well as
> > inner) are NOT NULL, should not it translate a NOT IN plan similar to
23 matches
Mail list logo
