On Wed, 2009-06-24 at 21:03 -0700, Chris St Denis wrote:
> This sounds like something that should just be on by default, not a
> trigger. Is there some reason it would waste the io of writing a new row
> to disk if nothing has changed? or is it just considered too much
> unnecessary overhead to
Dimitri Fontaine wrote:
Hi,
Le 24 juin 09 à 18:29, Alvaro Herrera a écrit :
Oleg Bartunov wrote:
On Wed, 24 Jun 2009, Chris St Denis wrote:
Is tsvector_update_trigger() smart enough to not bother updating a
tsvector if the text in that column has not changed?
no, you should do check yourse
Hi,
Le 24 juin 09 à 18:29, Alvaro Herrera a écrit :
Oleg Bartunov wrote:
On Wed, 24 Jun 2009, Chris St Denis wrote:
Is tsvector_update_trigger() smart enough to not bother updating a
tsvector if the text in that column has not changed?
no, you should do check yourself. There are several exa
As another poster pointed out, you cluster on ONE index and one index
only. However, you can cluster on a multi-column index.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Clustering reorganizes the layout of a table according to
the ordering of a SINGLE index. This will place items that
are adjacent in the index adjacent in the heap. So you need
to cluster on the index that will help the locality of
reference for the queries which will benefit you the most.
Executio
Hello,
I have a table like following. To increase the performance of this
table, I would like to create CLUSTER.
First, Which index should I use on this table for CLUSTER?
Secondly, Can I create multiple CLUSTER on the same table?
I will appreciate, if you can suggest other options to increase
Oleg Bartunov wrote:
> On Wed, 24 Jun 2009, Chris St Denis wrote:
>
>> Is tsvector_update_trigger() smart enough to not bother updating a
>> tsvector if the text in that column has not changed?
>
> no, you should do check yourself. There are several examples in mailing lists.
Or you could try usi
On Wed, Jun 24, 2009 at 9:52 AM, Tom Lane wrote:
> "Albe Laurenz" writes:
>> Robert Haas wrote:
>>> I don't think this is true. You can use SET SESSION AUTHORIZATION,
>>> right?
>
>> You are right, I overlooked that.
>> It is restricted to superusers though.
>
> That sort of thing is only workabl
"Albe Laurenz" writes:
> Robert Haas wrote:
>> I don't think this is true. You can use SET SESSION AUTHORIZATION,
>> right?
> You are right, I overlooked that.
> It is restricted to superusers though.
That sort of thing is only workable if you have trustworthy client code
that controls what q
Robert Haas wrote:
> > You cannot keep the connection and change users.
> > A change of database user always means a new connection and a new
> > backend process.
>
> I don't think this is true. You can use SET SESSION AUTHORIZATION,
> right?
You are right, I overlooked that.
It is restricte
Morning all,
A colleague here tried to post this yesterday but it was stalled for
some reason. Anyway, here's what we're seeing which hopefully someone
has some pointers for.
Essentially, we're seeing a query plan that is taking 95 secs with a
nested loop execution plan and 1 sec with a merg
On Jun 24, 2009, at 4:32 AM, "Albe Laurenz"
wrote:
Mike Ivanov wrote:
Please help me to make a decision on how to manage users.
For some reason it is easier in the project I'm working on to split
data
by schemes and assign them to Postgres' users (I mean those created
with
CREATE USER)
Mike Ivanov wrote:
> Please help me to make a decision on how to manage users.
>
> For some reason it is easier in the project I'm working on to split data
> by schemes and assign them to Postgres' users (I mean those created with
> CREATE USER) rather than support 'owner' fields referring to a
>>
>>> In our application we defer the updates to a separate asynchronous
>>> process using a simple queue mechanism, but in our case, we found that
>>> the updates are fast enough (in the order of a few milliseconds) not
>>> to warrant batching them into single transactions.
>>>
>>
>> A f
Craig James a écrit :
> Mathieu Nebra wrote:
>> Greg Stark a écrit :
>>> All the other comments are accurate, though it does seem like
>>> something the database ought to be able to handle.
>>>
>>> The other thing which hasn't been mentioned is that you have a lot of
>>> indexes. Updates require ma
On Wed, 24 Jun 2009, Chris St Denis wrote:
Is tsvector_update_trigger() smart enough to not bother updating a tsvector
if the text in that column has not changed?
no, you should do check yourself. There are several examples in mailing lists.
If not, can I make my own update trigger with som
Is tsvector_update_trigger() smart enough to not bother updating a
tsvector if the text in that column has not changed?
If not, can I make my own update trigger with something like
if new.description != old.description
return tsvector_update_trigger('fti_all', 'pg_catalog.english',
Mathieu Nebra wrote:
Alexander Staubo a écrit :
On Tue, Jun 23, 2009 at 1:12 PM, Mathieu Nebra wrote:
This "flags" table has more or less the following fields:
UserID - TopicID - LastReadAnswerID
We are doing pretty much same thing.
My problem is that everytime a user RE
18 matches
Mail list logo
