I don't think you 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 <wmo...@potentialtech.com>
--
Sent via pgsql-general mailin
he table don't seem 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 bl
ailable settings to tweak autovacuum behavior.
--
Bill Moran <wmo...@potentialtech.com>
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ocess.
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 <wmo...@potentialtech.com>
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
dexes that LIKE 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 <wmo...@potentialtech.com>
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
how to manage
it, and it's not part of the issue.
> 從我的 Samsung Galaxy 智慧型手機傳送。
> 原始訊息 自： Bill Moran <wmo...@potentialtech.com> 日期： 2017/5/24
> 20:24 (GMT+08:00) 至： pgsql-general@postgresql.org 主旨： [GENERAL] Current best
> practice for maximum shared_buffe
work
that's been done since 2012 to make large values work better?
--
Bill Moran <wmo...@potentialtech.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 Fri, 5 May 2017 19:52:42 +0100
Tony Finch <d...@dotat.at> wrote:
> Bill Moran <wmo...@potentialtech.com> wrote:
> >
> > There's a well-written article I saw recently that directly addresses
> > your question ... I'm too lazy to find it, but google wil
> I tried to find it, but failed. Can you give me some keywords to find
> this well-written article?
I can't seem find it again. Sorry.
--
Bill Moran <wmo...@potentialtech.com>
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscript
later implemented Redis 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 <wmo...@potentialtech.com>
--
Sent via pgsql-general mailing list (pgsql-general
with 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 <wmo...@potentialtech.com>
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ly transactions like this:
> >> > 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
y to run without ever needing 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, w
over essentially
duplicates a crash
on the PostgreSQL end when you failover.
--
Bill Moran <wmo...@potentialtech.com>
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
reat,
but they aren't quite 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 ha
ly?
Postgres' built-in streaming replication _does_ replicate this automatically.
--
Bill Moran <wmo...@potentialtech.com>
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
TER would be deferred indefinitely.
Personally, 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
On Wed, 08 Feb 2017 10:44:24 -0500
Tom Lane <t...@sss.pgh.pa.us> wrote:
> Albe Laurenz <laurenz.a...@wien.gv.at> writes:
> > Bill Moran wrote:
> >> What I feel is the best way to mitigate the situation, is to have some
> >> setting that limits the maximum
n'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 <wmo...@potentialtech.com>
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.or
ore.
Anyone know? Or, alternatively, anyone have another option to get the
same job done?
--
Bill Moran <wmo...@potentialtech.com>
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
have
any suggestions on what other ways the stats could be reset that I need to check
on? Has anyone else experienced this to lend credence to the possibility that
it's
a bug? I have no clue how to reproduce it, as the occurrance is rare and still
seems random.
--
Bill Moran <
ny more. So I must have just noticed it on a
particularly problematic day last time I looked.
--
Bill Moran <wmo...@potentialtech.com>
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
interrupted. I'm trying to understand if the partial runs are at least
making _some_ progress so the next vacuum has less to do, or if this is
a serious problem that I need to fiddle with tuning to fix.
--
Bill Moran <wmo...@potentialtech.com>
--
Sent via pgsql-general mailing list (pgsql-g
which does a count of the rows and if count is 3 it
> return false if count is less it returns true.
An exclusion constraint might be a better solution.
--
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
heme, a lot of developers don't
seem to think it's useful for them to know SQL, and therefore don't
bother trying -- or even actively resist learning.
So if the overall theme is "knowing this makes things better", I would
buy multiple copies of the book an mysteriously leave it on various
dev
ooks like the biggest pain point is the
inode_segments table, specifically, this condition:
s.full_path ~ '^/userfiles/account/[0-9]+/[a-z]+/[0-9]+'
It's doing a full scan of every record in that table, which is
a large number, and that regex can't be cheap over that kind of
volume.
If you do:
SELECT coun
it matter if they differ if you cannot recreate the correct one
> > exactly from source-controllled DDL? Or know how they are supposed to
> > differ if this is a migration point?
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make cha
gt; GRANT SELECT ON TABLE contracttype TO mro;
>
> It complicates the usage of pg_dump to compare the structures of the two
> similar databases like DEV and PROD, two development branches etc.
I don't think pg_dump was ever intended to serve that purpose.
dbsteward, on the other hand, do
gt; above?
> Do you have any idea what other systems to try?
http://dbsteward.org/
--
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
writes completed successfully, otherwise, Postgres would
be able to recover after a restart.
Beyond that, running Postgres on a filesystem that frequently fills up
is going to be problematic all around anyway. If you don't improve the
hardware situation, you're going to continue to have problems like this.
--
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
ach will only give you the former, whereas
CITEXT will give you both.
I don't think your syntax will work, though. I'm guessing that
PRIMARY KEY pk_stock_code lower(stock_code) will, though.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make c
t
you would expect, since a smaller index should be faster than a large one.
However, when it goes to actually fetch the row data, it takes
significantly longer on the small table, despite the fact that it's
only fetching 1/3 as many rows. It is, however, doing 2.5x as many
disk reads to get th
ying a set of columns as primary key also provides metadata about
the design of the schema, as a primary key implies that other tables can
rely on this set of columns as a unique identifier for rows. This
metadata may be used by external programs, but is also utilized interally
by the
acuum with appropriate
settings, they shouldn't need a VACUUM FULL again after that.
--
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, 28 Jan 2016 00:37:54 +0100
Ivan Voras <ivo...@gmail.com> wrote:
> On 28 January 2016 at 00:13, Bill Moran <wmo...@potentialtech.com> wrote:
>
> > On Wed, 27 Jan 2016 23:54:37 +0100
> > Ivan Voras <ivo...@gmail.com> wrote:
> >
> &g
On Tue, 19 Jan 2016 23:53:19 -0300
Alvaro Herrera <alvhe...@2ndquadrant.com> wrote:
> Bill Moran wrote:
>
> > As far as a current solution: my solution would be to decompose the
> > JSON into an optimized table. I.e.:
> >
> > CREATE TABLE store1 (
> &g
ded to that effect,
"Critical remarks regarding patches and/or technical work are
necessary to ensure a quality product; however, critical remarks
directed at individuals are not constructive and therefore not
acceptable." or something ...
--
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
ossible. It
will always involve _some_ pain, but less is better.
I've done the job of #3 with other groups, and 99% of the time
there was nothing to do. The one incident I had to handle was
terrible, but at least I had some guidance on how to deal with
it.
--
Bill Moran
--
Sent via pgsql-gener
that HSTORE is the right way to go, you may want to try
something more along the lines of this for your check:
SELECT true WHERE NOT EXISTS(SELECT 1 FROM keyz WHERE xfk NOT IN (akeys($1)));
Not tested, so it's possible that I have some typo or something; but overall
I've found that the NOT EXISTS
I seriously doubt that trying to make your UUIDs generate in a
predictable fashon will produce any measurable improvement, and I
see no evidence in the articles you cited that claims otherwise
have any real basis or were made by anyone knowledgeable enough
to know.
--
Bill Moran
--
Sent via pgsq
e doesn't mean it has to lie
> > about fsync, which is the only thing diskchecker.pl tests for.
> >
>
> I was thinking that since the disk have a 32M write-cache (with not
> battery) it would lie to the OS (and postgres) about when data are really
> on disk (not in the disk w
On Sun, 13 Dec 2015 16:35:08 +0100
Gerhard Wiesinger <li...@wiesinger.com> wrote:
> Hello Bill,
>
> Thank you for your response, comments inline:
>
> On 13.12.2015 16:05, Bill Moran wrote:
> > On Sun, 13 Dec 2015 09:57:21 +0100
> > Gerhard Wiesinger <l
> > -- idle again, memory still allocated
> > 26851 postgres 20 0 2365732 920668 918748 S 0.0 22.7 1:22.54
> > postgres: postgres postgres [local] idle
> >
> > Memory will only be released if psql is exited. According to the
> > PostgreSQL design memory shoul
mention that you see nothing in the PG logs, that makes it
even more likely (to me) that you're looking entirely in the wrong place.
I'd be willing to bet a steak dinner that if you put the web server on a
different server than the DB, that the memory problems would follow the
web server and not the DB server.
--
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 Sun, 13 Dec 2015 22:23:19 +0100
Gerhard Wiesinger <li...@wiesinger.com> wrote:
> On 13.12.2015 21:14, Bill Moran wrote:
> > Wait ... this is a combined HTTP/Postgres server? You didn't mention that
> > earlier, and it's kind of important.
> >
> > What e
non-function-calling SQL as well.
The third solution is probably _really_ the correct one, from
a pedantic standpoint, but it's a bit more work to implement.
--
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 Wed, 2 Dec 2015 09:31:44 -0800
Christophe Pettus <x...@thebuild.com> wrote:
>
> On Dec 2, 2015, at 9:25 AM, Bill Moran <wmo...@potentialtech.com> wrote:
>
> > No. See the section on row level locks here:
> > http://www.postgresql.org/docs/9.4/static/expli
If it's
happening frequently, you'll want to investigate what process is holding
the locks for so long and see what can be done about it.
--
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
answers available at this time. I'd really
like to build the alternate TOAST storage, but I'm not in a position to
start on a project that ambitious right ... I'm not even really keeping
up with the project I'm currently supposed to be doing.
--
Bill Moran
--
Sent via pgsql-general mailing li
R COLUMN $json_column SET STORAGE EXTERNAL;
?
The default storage for a JSONB field is EXTENDED. Switching it to
EXTERNAL will disable compression. You'll have to insert your data over
again, since this change doesn't alter any existing data, but see
if that change improves performance.
--
Bill M
fers value, and the rest of the data on the other
database server configured with higher shared_buffers.
I know these probably aren't the kind of answers you're looking
for, but I don't have anything better to suggest; and the rest
of the mailing list seems to be devoid of ideas as well.
--
Bill Moran
--
nfig you show) ... so are
you doing the inserts then checking the table without leaving enough time
in between for the system to wake up and notice the change?
--
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 Wed, 4 Nov 2015 16:43:57 +0100
Bertrand Roos <bertrand.r...@areal.fr> wrote:
>
> Le 04/11/2015 14:55, Bill Moran a écrit :
> > On Wed, 4 Nov 2015 14:32:37 +0100
> > Bertrand Roos <bertrand.r...@areal.fr> wrote:
> >> I try to configure auto-analys
urs, and the contents of the pg_locks table when
the problem is occurring.
--
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 startup of the server, or have some command
that tests to ensure the server is started and blocks until it is
before running the create command.
The only point I'm unclear on is whether you've confirmed that
Postgres actually _is_ started once the server is up (albiet without
the CREATE stateme
, and it does a pretty good
job of letting us coordinate activities. Basic membership on the
site is free and includes participating in as many groups as you
desire. (it only costs something if you want to host your own group).
Hope to see you soon.
--
Bill Moran
--
Sent via pgsql-general mailing
post to the hackers list
so the developers can chime in. My opinion is that this is a bug, but it's
an obscure enough bug that it's not surprising that it's gone unfixed for
a while.
--
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 large projects that keep the
session data in a Postgres table with great success.
--
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
Can anyone explain the best way to synchronise JUST the changes on a table
> between servers please?
Sounds like a problem custom-made to be solved by Slony:
http://slony.info/
--
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
d,relname), is it fisrt sort by oid then in the
> oid group sort by relname?
> Can somebody explain what does the database done for hashAggregate?
It combines the values for oid and relname for each returned row, generates a
hashkey
for them, then uses that hashkey to aggregate (compute the GR
see where it goes ...
> >
> > regards, tom lane
>
>
>
--
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
aspects of your I/O bandwith).
Am I missing something?
--
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
.
What problem are you seeing? What is your performance requirement, and what
is the observed performance? I ask because it's unlikely that you really
need to dig into these details like you are, and most people who ask
questions like this are misguided in some way.
--
Bill Moran
--
Sent via pgsql
never know what the performance
will be because you never know when some other VMs (completely unrelated
to you and/or your work) will saturate the IO with some ridiculous
grep recursive command or something.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
that redundancy, but when you do a pg_dump, all that
redundant data is reduced to a single CREATE INDEX command. The
result being that if your database has a lot of indexes, the pg_dump
might actually be faster.
But the only way to know is to try it out on your particular system.
--
Bill Moran
--
Sent
that with your help I'll be able
to solve this issue.
Best regards.
Lukasz
--
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 table_ebscb_spa_log02
FOR EACH ROW EXECUTE PROCEDURE on_ai_myTable();
If you created it with AFTER INSERT or FOR EACH STATEMENT, then the trigger
won't
work as desired.
The other thing about assignment being := was already mentioned.
--
Bill Moran
--
Sent via pgsql-general mailing list
in postgresql.conf.
Add it to the file.
Also, don't reply to unrelated threads with new questions, a lot of
people won't see your question if you do that, and if nobody sees
your question you won't get an answer.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
On Wed, 17 Jun 2015 10:33:37 -0300
Anderson Valadares anderva...@gmail.com wrote:
2015-06-15 18:19 GMT-03:00 Bill Moran wmo...@potentialtech.com:
On Mon, 15 Jun 2015 17:48:54 -0300
Anderson Valadares anderva...@gmail.com wrote:
2015-06-12 19:56 GMT-03:00 Bill Moran wmo
: The transaction might succeed if retried.
and
ERROR: could not serialize access due to read/write dependencies among
transactions
DETAIL: Reason code: Canceled on commit attempt with conflict in from
prepared pivot.
HINT: The transaction might succeed if retried.
Thanks!
--
Bill
data; you'd have to write your own or do it at the application
level.
--
Bill Moran wmo...@potentialtech.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 Mon, 15 Jun 2015 17:48:54 -0300
Anderson Valadares anderva...@gmail.com wrote:
2015-06-12 19:56 GMT-03:00 Bill Moran wmo...@potentialtech.com:
Please do not remove the mailing list from replies. See below.
On Fri, 12 Jun 2015 09:21:19 -0300
Anderson Valadares anderva...@gmail.com
Please do not remove the mailing list from replies. See below.
On Fri, 12 Jun 2015 09:21:19 -0300
Anderson Valadares anderva...@gmail.com wrote:
2015-06-08 20:33 GMT-03:00 Bill Moran wmo...@potentialtech.com:
On Mon, 8 Jun 2015 11:59:31 -0300
Anderson Valadares anderva...@gmail.com wrote
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Daniel Begin
Sent: June-03-15 06:32
To: 'Bill Moran'
Cc: pgsql-general@postgresql.org; 'Tomas Vondra'; 'Melvin Davidson'
Subject: Re: [GENERAL] Planner cost adjustments
Thank Bill,
About disks performance, all drives are identical
by dvi_sub.via_cod_viagem,
iti_sub.iti_cod_itinerario_linha, via_sub.equ_cod_eqpto
;
dvi_cod_dados_via_iti | via_cod_viagem
---+
1059964445 |7989813
1060072727 |7990876
(2 rows)
Time: 24.428 ms
Greetings
Anderson
--
Bill
manager which relies on virtual IP
management, not the one I described above.
pgpool has this capacity.
--
Bill Moran wmo...@potentialtech.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
, though.
--
Bill Moran wmo...@potentialtech.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
be:
ORDER BY c.created_at DESC
Not b, or as you noted its trivial to index. Sorry!
Creating an index on c.created_at sped things up by a factor of over
1000, which caused the case you defined to run in ~0.5ms for me.
--
Bill Moran wmo...@potentialtech.com
--
Sent via pgsql-general mailing list
is indicative of a pattern.
--
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
://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
On Fri, 22 May 2015 11:02:47 -0400
Tom Lane t...@sss.pgh.pa.us wrote:
Alban Hertroys haram...@gmail.com writes:
On 22 May 2015 at 04:46, Bill Moran wmo...@potentialtech.com wrote:
With all that being said, if I were to build a patch, would it be likely
to be accepted into core
On Fri, 22 May 2015 12:44:40 -0400
Tom Lane t...@sss.pgh.pa.us wrote:
Bill Moran wmo...@potentialtech.com writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Other questions you'd have to think about: what is the data type of
0x; what do you do with 0x (too big
On Fri, 22 May 2015 11:27:49 -0500
Dennis Jenkins dennis.jenkins...@gmail.com wrote:
On Fri, May 22, 2015 at 10:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alban Hertroys haram...@gmail.com writes:
On 22 May 2015 at 04:46, Bill Moran wmo...@potentialtech.com wrote:
With all that being
I'm working on a project converting a bunch of code from another database
system to PostgreSQL.
One of the issues is that the previous system accepted integers and binary
data in the same hex format as C ... i.e. 0xff
I understand that the proper way to handle this in postgres is x'ff', but
the
On Thu, 21 May 2015 13:57:24 -0400
Tom Lane t...@sss.pgh.pa.us wrote:
Bill Moran wmo...@potentialtech.com writes:
My other question: is there a specific reason why PostgreSQL doesn't support
this syntax, aside from nobody has bothered to add such support? Because
I'm considering writing
you whether the command to disable autocommit really is being issued
to
PostgreSQL as well ... so still might be useful.
--
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
find
any information on why that sit is down or where it might have
gone to.
Is this a temporary outage? Or has the RPM data moved somewhere
else and isn't documented yet? Any help is appreciated.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
is written in C, not in plpgsql. C has a good
optimizing compiler and plpgsql doesn't.
Maybe that's a roundabout way of saying that if your functions are
complex enough to require calling sub-functions they might be
justifying being writting in C?
--
Bill Moran
--
Sent via pgsql-general mailing list
and all the things that go with C aren't justified, because
plpgsql has none of that complexity. There are advantages both ways.
The beauty of PostgreSQL is that you have both available and you
can choose whichever is best for your situation.
--
Bill Moran
--
Sent via pgsql-general mailing list
(such as XML without proper
closing tags, etc). It seems that this strictness causes a lot
of people to avoid those data types, as there seem to be a lot
of people who would rather have garbage data in their database
than actually go to the work of fixing their application.
--
Bill Moran
aborting it. And the abort has to bubble up so
that other statements involved in the transaction are also notified.
--
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
what you want:
http://www.postgresql.org/docs/9.4/static/sql-savepoint.html
--
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
that would be helpful?
Don't know if I'm on the right track with this, but what is
maintenance_work_mem set to on this system?
--
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 Wed, 1 Apr 2015 06:26:36 -0700 (MST)
TonyS t...@exquisiteimages.com wrote:
On Wed, April 1, 2015 8:48 am, Bill Moran [via PostgreSQL] wrote:
Running analyze verbose; and watching top, the system starts out
using no swap data and about 4GB of cached memory and about 1GB of
used
,
Igor Neyman
Thanks Igor,
I will try changing that. I pretty much just let pgtune set all of those
values for me.
If pgtune set 1.5G of work_mem, then someone should file a bug report.
--
Bill Moran
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
on
a heavily updated table.
--
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
:
http://www.postgresql.org/docs/9.4/static/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS
--
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
the list. That's why I'm just looking for a lawyer who understands
the situation and can advise me.
On Wed, Mar 11, 2015 at 1:28 PM, Bill Moran wmo...@potentialtech.com
wrote:
I've been asked to sign a legal document related to a PostgreSQL-
related job opening. I have concerns
.
--
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
that, which would indicate that the folks
who made the snapshot didn't do it correctly.
--
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
1 - 100 of 821 matches
Mail list logo
