I am working on a project for which I require some assistance. Any input
would be appreciated.
We have a table with millions of records and dozens of columns. On some
systems, it takes up >10GB of disk space, and it runs on a single disk
which is rather slow (7200 RPM). We typically don't do any c
On Tue, Feb 25, 2014 at 11:17 AM, David Johnston wrote:
> David Johnston wrote
> >
> > Eliot Gable-4 wrote
> >> I advocated creating a separate mapping table which
> >> maps the ID of these records to the other ID we are searching for and
> >> performing
On Tue, Feb 25, 2014 at 3:13 PM, Eliot Gable wrote:
> On Tue, Feb 25, 2014 at 11:17 AM, David Johnston wrote:
>
>> David Johnston wrote
>> >
>> > Eliot Gable-4 wrote
>> >> I advocated creating a separate mapping table which
>> >> maps the ID
acuum.
Is this described behavior expected? If so, why?
If it is not expected, what should I be looking for which might explain why
it is taking so long?
Thanks.
--
Eliot Gable
"We do not inherit the Earth from our ancestors: we borrow it from our
children." ~David Brower
"I d
acuum
those tables. The auto vacuum already does a great job on those tables, so
I do not see why I should disable it on those.
Thanks in advance.
--
Eliot Gable
"We do not inherit the Earth from our ancestors: we borrow it from our
children." ~David Brower
"I decided the words
cannot even run psql to get into
the DB to run troubleshooting queries?
Thanks in advance for any suggestions.
--
Eliot Gable
"We do not inherit the Earth from our ancestors: we borrow it from our
children." ~David Brower
"I decided the words were too conservative for me. We'r
> most likely possibility you have a transaction being left open and
> accumulating locks. of course, you have to rule out the fact that
> you simply have to increase max_locks_per_transaction: if you have a
> lot of tables, it might be reasonable to have to extend this on a
> stock config.
>
>
W
> Another process comes along and processes records which are being inserted
> into the database. It pulls up to 10 records from a table, processes them,
> and moves those records into a "processed" table. The processing of the
> records is rather complex. To facilitate the processing, 6 temporary
x27; with the value of each row being equal
to the 'mydatasource' contents. Maybe there is a better way to achieve that
which someone can point out?
Thanks for any assistance anyone can provide.
--
Eliot Gable
"We do not inherit the Earth from our ancestors: we borrow it from our
childre
basically was that assigning a null to a composite
> variable would fail in some cases. If you weren't shooting yourself in
> the foot with naming conflicts, you might not trip over that case ...
> but an update to 8.4.recent wouldn't be a bad idea anyway.
>
>
On Fri, Jun 4, 2010 at 1:40 PM, Tom Lane wrote:
> Eliot Gable >
> writes:
> > Thanks for the note on the bugfix in the update. I will try it. However,
> > there is no naming conflict.
>
> There was most certainly a naming conflict in the sample code you
> pos
ail in some cases. If you weren't shooting yourself in
> the foot with naming conflicts, you might not trip over that case ...
> but an update to 8.4.recent wouldn't be a bad idea anyway.
>
>regards, tom lane
>
--
Eliot Gable
"We do not inhe
worried about how the planner might
re-arrange the joins on me, and I am wondering whether the order is
guaranteed to be preserved like this in the first place... Does anyone know
for sure about these assumptions?
Thanks in advance for any assistance.
--
Eliot Gable
"We do not inheri
Great suggestion. Thanks. Don't know why I didn't think of that. I do almost
exactly the same thing further down in my stored procedure.
On Mon, Jun 7, 2010 at 4:34 AM, Dimitri Fontaine wrote:
> Eliot Gable >
> writes:
>
> > I have a set of results that I am selectin
about the system.
Thanks.
--
Eliot Gable
"We do not inherit the Earth from our ancestors: we borrow it from our
children." ~David Brower
"I decided the words were too conservative for me. We're not borrowing
from our children, we're stealing from them--and it's no
execute a single transaction
where I run the stored procedure and fetch all results all at once. This was
working just fine a couple of days ago. Not sure what broke.
If anyone has any ideas on what might be going wrong here, I would really
appreciate some assistance.
Thanks in advance.
--
E
insert, update, or delete
operation on it?
Thanks in advance for any answers.
--
Eliot Gable
"We do not inherit the Earth from our ancestors: we borrow it from our
children." ~David Brower
"I decided the words were too conservative for me. We're not borrowing from
our chil
local node and any
remote systems the local node knows about.
So, how much of this is possible to do now with foreign tables, and how
much of it would I have to wait on? If I can do even some of it right now
with foreign tables, it would be useful.
--
Eliot Gable
"We do not inherit the
Is this bogus, or is it an upcoming feature?
http://wiki.postgresql.org/wiki/Lock_database
--
Eliot Gable
"We do not inherit the Earth from our ancestors: we borrow it from our
children." ~David Brower
"I decided the words were too conservative for me. We're not borrowi
differences in load?
--
Eliot Gable
"We do not inherit the Earth from our ancestors: we borrow it from our
children." ~David Brower
"I decided the words were too conservative for me. We're not borrowing from
our children, we're stealing from them--and it's not
ually?
Thanks in advance for any suggestions.
--
Eliot Gable
"We do not inherit the Earth from our ancestors: we borrow it from our
children." ~David Brower
"I decided the words were too conservative for me. We're not borrowing from
our children, we're stealing from them--a
ed statement handles? If such a method
exists, it would be far easier than looking through the DBIx::Class code
for unclosed statement handles.
Thanks for your suggestions.
--
Eliot Gable
if
all the rows are present.
Thanks in advance for any assistance.
--
Eliot Gable
ndividuals" function there is also VOLATILE and it calls
"summarize_user_log" which is also VOLATILE.
I cannot find a single non-volatile function in the call path; so I am
baffled on where this error message is coming from. I would be thankful for
any ideas anyone might have on wh
iduals" function there is also VOLATILE and it calls
"summarize_user_log" which is also VOLATILE.
I cannot find a single non-volatile function in the call path; so I am
baffled on where this error message is coming from. I would be thankful for
any ideas anyone might have on wh
No, I have lots of calls to current_timestamp inside volatile functions
which lock tables without complaints. I am beginning to think I hit some
sort of bug. This is PostgreSQL 9.0.1.
On Tue, Apr 17, 2012 at 5:55 PM, Michael Nolan wrote:
>
>
> On Tue, Apr 17, 2012 at 5:20 PM, El
On Tue, Apr 17, 2012 at 7:11 PM, Tom Lane wrote:
> Eliot Gable writes:
> > When the trigger fires, I get this in my postgres.log file:
> > 2012-04-17 16:57:15 EDT|test_db|169.254.5.138(56783)||[unknown]|30474
> > WARNING: Failed to materialize the live_user_activit
On Wed, Apr 18, 2012 at 10:18 AM, Eliot Gable <
egable+pgsql-gene...@gmail.com> wrote:
> On Tue, Apr 17, 2012 at 7:11 PM, Tom Lane wrote:
>
>> Eliot Gable writes:
>> > When the trigger fires, I get this in my postgres.log file:
>> > 2012-04-17 16:57:1
On Wed, Apr 18, 2012 at 1:01 PM, Tom Lane wrote:
> Eliot Gable writes:
> > While attempting to reproduce this issue in a sanitized set of tables,
> > functions, and triggers, I was able to locate the issue. Apparently I did
> > have another function call in there inside my
On Wed, Apr 18, 2012 at 3:47 PM, Tom Lane wrote:
> Eliot Gable writes:
> > On Wed, Apr 18, 2012 at 1:01 PM, Tom Lane wrote:
> >> However, there still might be an issue, because the CONTEXT trace that
> >> you showed certainly seemed to point where you thought it did.
control the order
in which both transactions grab locks on the different tables involved, and
each transaction may have an affect on the same rows as the other
transaction in one or more of the same tables.
--
Eliot Gable
"We do not inherit the Earth from our ancestors: we borrow it fro
On Fri, Apr 20, 2012 at 11:46 AM, Chris Angelico wrote:
>
> You have a Dining Philosophers Problem. Why can you not control the
> order in which they acquire their locks? That's one of the simplest
> solutions - for instance, all update locks are to be acquired in
> alphabetical order of table na
On Wed, Apr 18, 2012 at 3:47 PM, Tom Lane wrote:
> Eliot Gable writes:
> > On Wed, Apr 18, 2012 at 1:01 PM, Tom Lane wrote:
> >> However, there still might be an issue, because the CONTEXT trace that
> >> you showed certainly seemed to point where you thought it did.
33 matches
Mail list logo
