On Thu, Nov 23, 2017 at 1:28 AM, Alexander Pyhalov wrote:
> On 11/22/17 07:24 PM, Magnus Hagander wrote:
>> What is your postgres version, and what's the "version history" of
>> upgrades
>> from it (talking pg_upgrade upgrades, not dump/reload upgrades). This
>> might
>> be fallout from old bugs t
2017-11-24 17:55 GMT+01:00 Tom Lane :
> bricklen writes:
>
> > If you are on a (non-production) *nix server you can use:
> > sync && echo 3 > /proc/sys/vm/drop_caches
>
> You would also need to restart the postmaster, to get rid of whatever
> is in Postgres' shared buffers.
>
And restart postgr
On 11/24/2017 11:43 AM, Michael Nolan wrote:
There are so many different levels of caching going on--within
Postgresql, within the OS, within a disk array or SAN, and at the
individual drive--that there may no longer be a meaningful way to
perform this measurement.
generally, power cycling t
On Fri, Nov 24, 2017 at 8:54 AM, hmidi slim wrote:
> I'm trying to analyze some queries using the explain instructions and the
> option analyze and buffers. I realized that the query refers to the cache
> memory to return the results. Is there any solution to clear the cache in
> postgresql inord
I execute the command sync && echo 3 > /proc/sys/vm/drop_caches but I
still got buffers hit added to that buffers read now.Why I got the buffers
hit?
2017-11-24 17:55 GMT+01:00 Tom Lane :
> bricklen writes:
> > On Fri, Nov 24, 2017 at 6:54 AM, hmidi slim
> wrote:
> >> I'm trying to analyze som
bricklen writes:
> On Fri, Nov 24, 2017 at 6:54 AM, hmidi slim wrote:
>> I'm trying to analyze some queries using the explain instructions and the
>> option analyze and buffers. I realized that the query refers to the cache
>> memory to return the results. Is there any solution to clear the cache
On Fri, Nov 24, 2017 at 6:54 AM, hmidi slim wrote:
> I'm trying to analyze some queries using the explain instructions and the
> option analyze and buffers. I realized that the query refers to the cache
> memory to return the results. Is there any solution to clear the cache in
> postgresql inord
I'm trying to analyze some queries using the explain instructions and the
option analyze and buffers. I realized that the query refers to the cache
memory to return the results. Is there any solution to clear the cache in
postgresql inorder to get execution time of the query when it get data from
d
with this query:
explain (ANALYZE,BUFFERS) SELECT p.*FROM place as p, user as u where
p.id = u.place_id
and to_tsvector('simple', p.name) @@ to_tsquery('simple', 'a:*') and
u.status = true;
I got the buffers.I think that is not working with JOIN INNER.
2017-11-24 13:46 GMT+01:00 Luca Ferrari :
On 11/23/2017 09:58 PM, Tom Lane wrote:
> Dmitry Lazurkin writes:
>> Datum
>> gtrgm_out(PG_FUNCTION_ARGS)
>> {
>> GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0); /* I think entry
>> is pointer to bad memory */
> The argument is TRGM *, I think ... certainly not GISTENTRY *.
>
>
On Fri, Nov 24, 2017 at 12:30 PM, hmidi slim wrote:
> I didn't get the number of read and hit buffers when I rexecute the query
> many times.How can I Fix that? and I tried the options costs, timing and I
> got the same plan query however when trying the option format json it works.
Not sure but
I'm trying to anlayze a query in postgresql v9.6.4:
explain (ANALYZE,BUFFERS) SELECT p.*
FROM place as p INNER JOIN user as u ON p.id = u.place_id
where to_tsvector('simple', p.name) @@ to_tsquery('simple', 'a:*') and
u.status = true;
The QueryPlan was :
Hash Join (cost=20.28..3
Hi craig,
I have a bunch of orphaned replication identifier.
How to cleanup those orpaned identifier without affecting currently
configured slots?
I mean what is relation the replication identifier with slot_name in
replication slots?
On Mon, Sep 18, 2017 at 3:00 PM, milist ujang
wrote:
> Hi
On Fri, Nov 24, 2017 at 3:46 AM, support-tiger wrote:
> Oleg,
>
> hey, thanks so much - if you are in USA visiting Yellowstone Natl Park
> contact me and the beer is on me (maybe a Wyoming steak too!)
Seriously ?
btw, in PG 11 we expect subscription index
update test set data[age]= '30';
Source is good enough in my case and I planned to grep it anyway, so thanks
for saving my time!
2017-11-24 10:15 GMT+03:00 Laurenz Albe :
> Nikita wrote:
> > 1. pg_total_relation_size return predictable approximately correct table
> size (apart from some preallocation) without subsequent
> VACUUM
15 matches
Mail list logo
