use it's
returning 1 row. No matter what you alias the result to, it's not going
to change the result, unless of course you try to alias it to an SQL
reserved word, such as "none", without quoting it. Of course, if you
include the optional AS, it probably makes more sense what&#x
On Wed, Mar 09, 2011 at 05:51:51PM -0800, abcdef wrote:
> Hi, I use postgres in red hat linux .
> When I use psql and select the content of the table .
> I find the format is not tidy .
> I change align and unalign , the output is not filful my requirement.
> Any special setting that can change the
rs, bears, statecode FROM WildLife
WHERE state_pt = statecode;
However when I try anything other than a constant, it search EVERY
partition, sequentially, which is not what I want it to do. So is there
any way to specify the partition to search using a variable/column name?
--
*Bill Thoen*
GISnet
On 3/15/2011 12:02 PM, Igor Neyman wrote:
-Original Message-
From: Bill Thoen [mailto:bth...@gisnet.com]
Sent: Monday, March 14, 2011 11:31 PM
To: pgsql-general@postgresql.org
Subject: Partitioned Database and Choosing Subtables
I've got a ver 8.4.5 partitioned data base with re
n
you mix deadlines with ignorance.
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
Good point. I'm feeling a bit chainsaw-ish right now.
--
*Bill Thoen*
GISnet - www.gisnet.com
303-786-9961
--
Sent via pgsql-general mailing list (pgs
n
the file server.
Never measured the actual performance difference, but we haven't
had any performance issues with keeping the data in the DB. I'm
sure keeping it on the filesystem is faster, though.
--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmor
ables will
always be rounded to an even page size. With only 1 row, it's always
going to take a minimum amount.
Also, are you sure you're storing compressible data? For example, if
you're putting PNG or JPEG images in there, they're not going to compress
any.
--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
2
(1 row)
db=# show vacuum_freeze_min_age;
vacuum_freeze_min_age
---
5000
(1 row)
db=# show vacuum_freeze_table_age;
vacuum_freeze_table_age
-
15000
(1 row)
Thanks in advance for any advice
Bill
ication servers with these
> configuration settings:
>
> pool_mode = transaction
> default_pool_size = 20
> max_client_conn = 125
> query_wait_timeout = 2
> server_idle_timeout = 60
>
> Jaco
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
in Postgres just like you
can in MySQL (in fact, it's more reliable in Postgres) so I don't
understand why you can't continue to do it that way.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
and for some reason remembered it now:
https://schemaverse.com/
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
cuumed within 2645303 transactions.
>
> The value of number of transactions is going down every minute
>
> Can anyone tell me what is the best way to sort up this issue.
>
> Thanks
> Avi
>
>
>
>
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
or.
>
> I also use SSL connections, is this the problem? or in other words is
> there a way to connect php via (postgres) ssl?
Have you tried using sslmode or requiressl in the $connect string?
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
it with me: An RDBMS is not RAM, and trying to use
it like RAM will probably lead to disappointing performance.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Thu, 10 Jul 2014 08:40:59 -0700 (PDT) AlexK wrote:
> Bill,
>
> Regarding "SELECT performance improve nearly linerally to the number of
> partitions," - can you elaborate why? If I split my table into several
> partitions, even the index depth may stay the same, becau
_never_ changes, and he access patterns dictate it, there's no reason
not to CLUSTER, but I'm not convinced that you'll benefit (again, there's
a lot of information about your application use that hasn't been provided
that's necessary to make such a determination)
--
e level of performance? Has he even tested to see if the existing
layout will scale acceptably to the expected data volume? (perhaps nothing
needs to be changed at all) We don't know, so we can only speculate.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
the
POSIX versions of Postgres allocate shared_buffers worth of memory at startup
and lock it for exclusive use by Postgres. Do you have shared_buffers set to
around 1G, perhaps?
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
xes at will. That type of easter egg
hunt may not be necessary, though. EXPLAIN ANALYZE can often tell you if the
plan
is bad by showing you where estimated times vary wildly from actual times.
Hope this helps, but before you worry too much about it, I'd suggest asking
yourself 1 question: is
On Fri, 25 Jul 2014 17:20:57 +0100
Rebecca Clarke wrote:
> Hi Bill,
>
> Thanks for the reply. Here's the EXPLAIN output of a couple of the queries:
A few suggestions in addition to David's comment about doing
EXPLAIN ANALYZE:
1) When experimenting, one thing to try might
log table
(See attached file: create_log_utilities.sql)- Code to create the two
logging functions
(See attached file: test_log_utilities.sql)- Code to exercise the msg and
error logging functions
Thanks.
Bill
_
William Epstein
Consulting I/T Specialist
AIS ADM
bles then a bug in the code can
allow an accidental or malicious user to quickly and easily destroy data.
--
Bill Moran
I need your help to succeed:
http://gamesbybill.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
full data set in QA
I would have thought that shipping WAL file into S3 would have been problematic
- I'd be interested in the size of the data set and the experiences you've had
with that
Regards
Bill
Sent from my iPhone
> On Aug 14, 2014, at 12:17, "Andy Lau" wrote:
&g
the ability
to go to a specific point in time hasn’t been a concern for us.
Thanks for the reply!
Bill
From: Andy Lau mailto:a...@infer.com>>
Date: Tuesday, August 19, 2014 at 3:04 PM
To: Joseph Kregloh mailto:jkreg...@sproutloud.com>>
Cc: WILLIAM MITCHELL mailto:b...@publicrelay.co
ve to fetch most of the rows from ticket anyway, which is a logical reason
for it to skip the index and just do a seq scan. Can you confirm/deny whether
that's the case? If not, and you're analyzing the tables often enough, you
may need to raise your statistics target on those tables.
--
Bill Moran
I need your help to succeed:
http://gamesbybill.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ry_ (although they're nice to have). When it comes
down to work done for employer, it was just less effort to succeed by going the
route of using the existing plSQL/plPGSQL, and employers are all about less
money spent to accomplish the goal.
Other people may have other opinions or stories or
k_descriptors TYPE VARCHAR;
would do nothing more than change the table definition. There is no need for
that statement to touch any data.
However, adding the length constraint of (1024) will force Postgres to check
every single value to ensure it complies with the constraint. I believe if
any
antage of slony is that you can install it without stopping the
DB server, wait patiently while it takes however long is needed to synch up
the two servers without having much impact (if any) on operations, then switch
over when you're ready. The disadvantage to Slony is that the setup/config
improve on the
situation
by tweaking the autovacuum settings for this table to vacuum it more
aggressively.
Although, you don't seem to have a _problem_ that you've stated. Are you seeing
performance issues? Is 33M too much data and filling up the drive (not being
sarcastic here, as t
em close the program. IMHO, too many
GUI tools make it too easy to do something without realizing the
consequences.
On a related note, I'm curious as to how an open transaction affects HOT
updates (if at all). This is an area of behavior I have little experience
with to date.
--
Bill M
nnectors?
I'm not aware of any, and in my previous job we made extensive use of it.
--
Bill Moran
I need your help to succeed:
http://gamesbybill.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
that such an
approach _appears_ to fix the problem, because the faster hardware causes the
chance of the problem occuring to be less, and in the mind of people who don't
understand concurrent programming, that's "fixed".
The amount of really badly written software out there
_xt_data.ael_id = gf_proc.get_aelid_sbo(old.sbo_grp) AND
> ael_xt_data.en_name::text = old.en_name::text
> ael_xt_data_view_ur AS
> ON UPDATE TO ael_xt_data_view DO INSTEAD UPDATE ael_xt_data SET
> en_name = new.en_name, sbo_key = new.sbo_key, ael_id =
> gf_proc.get_aelid_sbo(new.sbo_grp), num_of_s
ion until a web browser responds is
putting the ability to lock your database solid into the hands of anyone who
can access your web site.
HTH
--
Bill Moran
I need your help to succeed:
http://gamesbybill.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
dard, but I could be wrong on this count. Quite frankly, I don't see any
reason for anyone using char any more. If I had to guess, I would guess that
char
is in the standard because at the time of creation there were systems that could
heavily optimize access to fix-width fields, and that it&#x
, person2 AS friend FROM friendship
UNION
SELECT person2 AS person, person1 AS friend FORM friendship;
That should be a very performant view when a WHERE clause on person is
specified.
Those types of queries weren't a requirement in the implementation I did,
as the code only ever asked "
as that databases went under
/var/db, so all our PostgreSQL servers used /var/db/postgres
/var/db was also usually a dedicated mount point connected to a fast
RAID-10 drive array.
Never had any trouble with it.
--
Bill Moran
I need your help to succeed:
http://gamesbybill.com
--
Sent via pgsql-gen
far better off
doing the research until you know enough to pick between pgcrypto and
pycrypto on your own.
--
Bill Moran
I need your help to succeed:
http://gamesbybill.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
abling that will remove a lot of the red herrings from your error output.
--
Bill Moran
I need your help to succeed:
http://gamesbybill.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
on-specific PostGIS stuff before loading that into the new
server.
Then do a pg_dump -a to dump all the data and load that. Whether that works
depends on how much has changed bewteen PostGIS versions -- I haven't worked
with
PostGIS in almost a year, so I don't know for sure if it
event_ptr_id =
> ev.id
>LEFT JOIN public.device_photoevent AS pev ON pev.basicgpsevent_ptr_id =
> ev.id
>WHERE TRUE )
> SELECT *
> FROM x
> ORDER BY x.x_event_time ,
> x.x_system_time ;
>
>
> >
> > Well this is coming from the ker
i.e., have you
confirmed that these are the _only_ tables causing the deadlock?
Since you didn't include any log output, I'm fuzzy on some of those things
above ... but I'm assuming that you're unable to post specific details of
the precise problem.
I have a lot of suggestions,
e more definite, but
I don't have access to the information any more.
On a related note, I remember that the sysops guys had a list of mount options
that they used to improve performance ... noatime being one that I remember,
but whatever filesystem you use, be sure to research and tweak the
On Tue, 25 Nov 2014 17:27:18 +0100
Christoph Berg wrote:
> Re: Bill Moran 2014-11-25
> <20141125111630.d05d58a9eb083c7cf80ed...@potentialtech.com>
> > Anything with a journal is a performance problem. PostgreSQL effectivly
> > does its own journalling with the WAL logs
nd a definitive statement to that
effect.
Since stored procedures written in SQL are unable to return the trigger type,
it's not currently possible to write triggers in SQL.
--
Bill Moran
I need your help to succeed:
http://gamesbybill.com
--
Sent via pgsql-general mailing list (
imes a day, and the solution I'm proposing won't
have any performance impact on the other 1300 queries per day that
don't deadlock.
2-3 deadlocks per day is normal operation for a heavily contented table,
in my experience.
--
Bill Moran
I need your help to succeed:
http://
t; and bl.pid <> kl.pid
> JOIN pg_catalog.pg_stat_activity ka
> ON kl.pid = ka.pid
> WHERE kl.granted and not bl.granted
> ORDER BY a.query_start;
>
> Regards...
--
Bill Moran
I need your help to succeed:
http://gamesbybill.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
BLE table_name
ALTER COLUMN col_name TYPE integer
USING CAST(col_name AS INT);
Which will work as long as all the values can be cast to an INT without
error. If you have values that can't be cast without error, you'll have
to fix them before you can do the ALTER.
--
Bill Moran
I need
On Thu, 27 Nov 2014 15:07:49 +1100
Sanjaya Vithanagama wrote:
> On Wed, Nov 26, 2014 at 11:47 AM, Bill Moran
> wrote:
>
> > On Wed, 26 Nov 2014 10:41:56 +1100
> > Sanjaya Vithanagama wrote:
> > >
> > > > * How frequently do deadlocks occur?
> >
> table? I am running a fairly vanilla postgres 8.4 db on linux, with a few
> minor tweaks to postgresql.conf:
I would tell you to look at the pg_stat_all_tables view, but I'm not even sure
if the ancient, unsupported 8.4 version of PostgreSQL had that table.
--
Bill Moran
I need
tertiary1 (
parent_id INT REFERENCES secondary(parent_id),
... additional fields ...
);
CREATE table tertiary2 (
parent_id INT REFERENCES secondary(parent_id),
... additional fields ...
);
This is only possible if there's only one secondary row per row in main,
so it may not work for you.
and the QA practices you enforce.
Summary: if data quality is important, PostgreSQL is probably the right choice.
If you are OK with some poor quality data, and really need the features of
Riak, then go that route.
--
Bill Moran
I need your help to succeed:
http://gamesbybill.com
--
Sen
e found
that bytea is usually the correct storage method for things like PDF
files, wordprocessor files, images, etc ... anything where the entire
file needs to be delivered before it can be used.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
g_depend|5.3 |3948544 |
> pg_depend_reference_index | 337.0 |156901376
> pg_catalog | pg_depend|5.3 |3948544 | pg_depend_depender_index
> | 359.6 |167436288
> pg_catalog | pg_index|6.1 |1130496 | pg_index_indexrelid_index
> | 72.9 |
geobject is locked, lots of our website doesn't
> work.
Sometimes CLUSTER is faster than VACUUM FULL ... have you tested CLUSTERing
of pg_largeobject on your test system to see if it's fast enough?
How big is the non-lo data?
--
Bill Moran
--
Sent via pgsql-general mailing li
On Tue, 3 Feb 2015 14:17:03 -0500
Adam Hooper wrote:
> On Tue, Feb 3, 2015 at 12:58 PM, Bill Moran wrote:
> > On Tue, 3 Feb 2015 10:53:11 -0500
> > Adam Hooper wrote:
> >
> >> This plan won't work: Step 2 will be too slow because pg_largeobject
> >&g
On Tue, 3 Feb 2015 14:48:17 -0500
Adam Hooper wrote:
> On Tue, Feb 3, 2015 at 2:29 PM, Bill Moran wrote:
> > On Tue, 3 Feb 2015 14:17:03 -0500
> > Adam Hooper wrote:
> >
> > My recommendation here would be to use Slony to replicate the data to a
> > new serv
a test environment will be destroyed when the
database is dropped. There are some exceptions, such as roles and
users, but I wouldn't think you would need to wipe/recreate those.
In any event, don't know if that suggestion will help, but it's
what was successful for me.
--
es and amount of RAM available to the process,
but sometimes, when the transfer of data from the database to the other
code is the bottleneck, the opposite is true.
Sorry that I'm saying "it depends" so many times, but hopefully the details
on how it depends will help you make decisions, or at least tell you what
to investigate to decide.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ettings\Temp\postgresql_installer_dc46cfee2c\getlocales.exe
>
>
>
>
> + The Forestry Commission's computer systems may be monitored and
> communications carried out on them recorded, to secure the effective
> operation of the system and for other lawful purposes. +
&g
nd Vick's comments on selecting the partition ahead of time,
in particular, we realized HUGE performance gains on inserts when our code
determined the partition ahead of time and inserted directly into the
partition instead of into the primary table.
--
Bill Moran
--
Sent via pgsql-gener
On Fri, 13 Feb 2015 16:29:02 +
Seref Arikan wrote:
> Hi Bill,
> Could you point at some resource(s) that discuss inserting directly into
> the partition?
Not off the top of my head, I would have to google just like
you would.
> Would it be possible to read directly from the
hat such a thing is necessary or desirable? Simply add the
columns to the GROUP BY clause and make the request unambiguous.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Fri, 13 Feb 2015 10:48:13 -0800
Jeff Janes wrote:
> On Fri, Feb 13, 2015 at 10:26 AM, Bill Moran
> wrote:
>
> > > Ryan Delaney writes:
> > > > Why couldn't an RDBMS such as postgres interpret a SELECT that omits
> > the GROUP
> > > > BY
gt;
> > I don't think your plan for 365 partitions is outrageous on modern large
> > hardware. For 1000 partitions, I don't know. It will depend on how you can
> > optimize your queries before giving them to postgres.
> >
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
application will see the most
benefit by super-optimizing that request. There's no one answer that's
right for every situation ... at least not in my experience.
> On Sat, Feb 14, 2015 at 11:15 AM, Bill Moran
> wrote:
>
> > On Sat, 14 Feb 2015 11:14:10 +1300
> > Tim Uck
der a
tremendous load, the second attemp usually succeeds (of course,
there is a chance that it will deadlock again, so you have to
take into account that it might take an arbitrary number of
attempts before it succeeds)
I've seen this all too many times: many application developers
assume
q1
SAVEPOINT q2
Q2 -> failure
ROLLBACK TO SAVEPOINT q2
SAVEPOINT q3
Q3 -> success
RELEASE SAVEPOINT q3
COMMIT
In which case Q1 and Q3 would successfully be committed.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
y happening more
frequently than necessary because of the bug he mentioned ... so
upgrading may cause the problem to happen infrequently enough that
you don't really care about it. The solutions I suggest are still
relevent, they just might not be as immediately important.
--
Bill Moran
On Thu, 19 Feb 2015 11:12:38 +0530
Medhavi Mahansaria wrote:
> Hi Bill,
>
> Thanks!
>
> But savepoint concept will not work for me as desired.
Why not? The scenerio you describe below can be perfectly implemented
using savepoints. Describe in more detail, please, why s
people didn't understand it. If my comments don't
address your question, perhaps try describing it differently.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
> --
> 825472959-2013-03-15 10:28:16 MSK OhGha5ya@rzdvo 5616 LOG: process
> 5616 still waiting for AccessExclusiveLock on object 0 of class 1262
> of database 0 after 3000.112 ms
> 825473118:2013-03-15 10:28:16 MSK OhGha5ya@rzdvo 5616 STATEMENT:
> NOTIFY test, ''
psql -U postgres
psql (9.2.3)
Type "help" for help.
postgres=# select encode('can''t', 'escape');
encode
can't
(1 row)
I observed the same behaviour on one of our older systems (8.3.11) as well.
Am I missing something? I expected
In response to Merlin Moncure :
> On Tue, Mar 26, 2013 at 12:47 PM, Bill Moran wrote:
> >
> > psql -U postgres
> > psql (9.2.3)
> > Type "help" for help.
> >
> > postgres=# select encode('can''t', 'escape');
> >
In response to Clemens Eisserer :
>
> Is there any way to listen to NOTIFY in php without polling using a
> callback or blocking call?
Not at this time.
--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/
--
Sent via pgsql-general mailing li
rever and send it to the server.
Or just use the one built in to psql, as Jasen suggested.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
You can do select pg_cancel_backend(8243);
and that should terminate that process that is sending, but still leave
your postgres server healthy.
regards,
Bill
On 7/8/13 5:31 AM, Jov wrote:
> one of our pg user send a select * from 10 million table without limit
> from psql,before get the
Hmm..
In that case, I think that select pg_terminate_backend() might be in order?
http://www.postgresql.org/docs/9.1/static/functions-admin.html
regards,
Bill
On 7/8/13 5:46 AM, Jov wrote:
> we do select pg_cancel_backend(8243) several times,but the backend
> still hang there.
>
>
ply not
finding it for some reason?
Assuming this doesn't exist (I haven't found it) my next question is
whether there's a philosophical or technical reason that such a feature
doesn't exist? Should I take this discussion to -hackers?
--
Bill Moran
--
Sent via pgsql
On Wed, 08 Feb 2017 10:44:24 -0500
Tom Lane wrote:
> Albe Laurenz writes:
> > Bill Moran wrote:
> >> What I feel is the best way to mitigate the situation, is to have some
> >> setting that limits the maximum RAM any backend can consume.
>
> > I'd dele
ally, I feel like the existing behavior is preferrable. Software
teams need to take the time to understand the locking implications of their
actions or they'll have nothing but trouble anyway.
As I've seen time and again: writing an application that handles low load
and low concurrency is f
ucardo for replication, but this feature doesn't work, we need
> to manually do it on the
> SLAVE and some other steps to have both DB sync.
>
> We already know how to do it, bucardo works.
>
> Just wondering if PSQL can handle this automatically?
Postgres' built-in s
perfect if they don't know what is being done with
the data on the drives.
Whether it's good enough depends heavily on what your expectation is.
Before trusting it to meet your needs, I would spend some time simulating
failures and seeing what actually happens.
--
Bill Moran
--
s a crash
on the PostgreSQL end when you failover.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
eeding to access the actual
table; but I'm just speculating.
In my experience, queries like these rarely benefit from filter indexes,
because most of the time involved is in the grouping and aggregate processing,
and the index does nothing to help with that. But, again, without EXPLAIN
output
his:
> >> > select * from dati256 where id >4300 limit 100;
> >> > I don't understand why are there WAL writings during read only
> >> transactions.
These are hint bits. The mechanism and behavior are known and documented:
https://wiki.postgresql.
h something
specifically designed for that purpose.
Of course, if you need structured, relational data to be stored reliably,
you can't do much better than Postgres.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
when our caching requirements exceeded
what Postgres could do in that capacity. We never switched to
anything else for blob storage, as Postgres was always sufficient.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://w
ut failed. Can you give me some keywords to find
> this well-written article?
I can't seem find it again. Sorry.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Fri, 5 May 2017 19:52:42 +0100
Tony Finch wrote:
> Bill Moran wrote:
> >
> > There's a well-written article I saw recently that directly addresses
> > your question ... I'm too lazy to find it, but google will probably
> > turn it up for you.
>
>
lopers care to comment on any work
that's been done since 2012 to make large values work better?
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
age
it, and it's not part of the issue.
> 從我的 Samsung Galaxy 智慧型手機傳送。
> 原始訊息 自： Bill Moran 日期： 2017/5/24
> 20:24 (GMT+08:00) 至： pgsql-general@postgresql.org 主旨： [GENERAL] Current best
> practice for maximum shared_buffers settings on big hardware?
>
> A f
E can use
to do index searches instead of always having to do sequential scans
or push the LIKE matching to another part of the plan tree. Based on
your described situation, I have a theory that it might improve things
quite a bit.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
esting process.
In any event, if your testing doesn't help any; you'll probably need to
include answers to at least the above questions before the list will be
much help.
That is, of course, unless someone familar with pointcloud has seen this
exact problem and already knows the answer ...
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
.
See ALTER
TABLE and the available settings to tweak autovacuum behavior.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
eem to be re-used.
It's possible that the early pages don't have enough usable space for the
updated
rows. Depending on your update patterns, you may end up with bloat scattered
across
many pages, with no individual page having enough space to be reused. That seems
unlikely as the blo
can do exactly what you're asking. However, you should
be able to achieve the same result by setting a default schema for the
user that you're connecting as. See the docs for ALTER ROLE and SET.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To ma
.e. the user
> interface when displaying sadg: "postal address" would always pull all
> attributes in that group and lay-out would automatically handle the new
> attributes).
Sounds like LDAP.
--
Bill Moran
http://www.potentialtech.com
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
ry matching the column
name exactly and putting "" around it. If that doesn't work, provide some
more information in your question.
-Bill
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
e whatever
tools you want to analyze it, but I've found pgFouine to be particularly
helpful in isolating slow queries.
--
Bill Moran
http://www.potentialtech.com
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
301 - 400 of 1196 matches
Mail list logo
