). I try to avoid BLOBs whenever possible.
Cheers,
Jeremy Haile
On Fri, 5 Jan 2007 17:18:10 -0200, Clodoaldo
[EMAIL PROTECTED] said:
5 Jan 2007 06:59:18 -0800, imageguy [EMAIL PROTECTED]:
I think I know the answer,
If you know the answer please tell it as I have read some discussions
How does it make it easier to control access and security? If your web
app makes a decision about allowing access to the database, it can just
as easily make a decision about allowing access to the filesystem.
Storing the images on the file system doesn't mean that there isn't a
piece of code
Nope - the other way around. The vacuumdb tool simply executes the
VACUUM command through postmaster.
On Fri, 05 Jan 2007 15:05:44 -0600, Erik Jones [EMAIL PROTECTED] said:
Quick question, when running a VACUUM query through the postmaster,
does it use the external vacuumdb tool?
--
Yeah - it can make it easier to implement transactional semantics by
storing them in the database, although for simple operations it wouldn't
be hard to replicate this manually. And you are going to incur a
performance penalty by storing them in the database.
Another thing to consider is that
clearly superior - but I don't think
we know enough details to make that call)
My two cents,
Jeremy Haile
On Fri, 05 Jan 2007 20:24:05 -0200, Jorge Godoy [EMAIL PROTECTED]
said:
Jeremy Haile [EMAIL PROTECTED] writes:
Another thing to consider is that storing them in the file system makes
it much
I wonder why this HTTP cache headers argument didn't surface in this
heated debate.
I mentioned this earlier as well. Although you could do it in the app
layer - it would be easier to just let the web server handle it.
---(end of broadcast)---
Note that things will go faster if you do your initial data load using
copy from stdin for the initial bulk data load. individual inserts in
postgresql are quite costly compared to mysql. It's the transactional
overhead. by grouping them together you can make things much faster.
copy from
I have a process that appears to hang every night. I ran the following
query and results, and it looks like an autoanalyze and query are
waiting on a lock that's being exclusively held by a transaction that is
IDLE. Any ideas? Any additional queries I should run to shed light on
the issue?
I second the desire for a UUID type in PostgreSQL! I'm aware of the
pguuid project, but it's not the same as having it in core and isn't
very well maintained.
This is such a common database paradigm that it seems reasonable to
promote it to first-class citizen status in PostgreSQL.
I
Yeah, but it's not going to be added to core until there's some
agreement about *what* needs to be added. The point of the external
project is that once it has acheived a level of support *then* it can
be incorporated.
That's fair. In truth, I only found that pguuid existed fairly recently
Is it feasible to add a reindex concurrently that doesn't lock the
table for the rebuild, then locks the table when doing a second pass to
pickup rows that were changed after the first pass? Or something like
that
On Fri, 19 Jan 2007 12:45:03 -0500, Tom Lane [EMAIL PROTECTED] said:
Ed L.
That's interesting. So if you have a composite index on two columns, is
there much of a reason (usually) to create single indexes on each of the
two columns? I guess the single indexes might be slightly faster
depending on the number of different values/combinations, so probably
it depends eh?
But there are ways that we could optimize count(*) queries for specific
circumstances right? Obviously this isn't trivial, but I think it would
be nice if we could maintain a number of rows count that could be used
when performing a count(*) on the whole table (no where clause).
I don't know
I've noticed that my tables are not being auto vacuumed or analyzed
regularly, even though I have very aggressive autovacuum settings.
The stats collector appears to still be running, since I can see a
postgres.exe process with -forkcol. However, I never notice it using
I/O or CPU usage.
pgstat.stat was last updated 1/22 12:25pm - there is no pgstat.tmp.
Coincidentally (I think not) - the last auto-analyze was performed at
2007-01-22 12:24:11.424-05.
The logs for 1/22 are empty - so no errors or anything like that to give
clues...
Thanks!
Jeremy Haile
On Wed, 24 Jan 2007 14
involved in these - did you ever figure out how to
resolve the issues of the stats collector getting stuck in Windows?
Thanks, Jeremy Haile
On Wed, 24 Jan 2007 14:19:05 -0500, Jeremy Haile [EMAIL PROTECTED]
said:
pgstat.stat was last updated 1/22 12:25pm - there is no pgstat.tmp
Tom,
Did this information shed any light on what the problem might be? Any
solution or workaround?
Thanks!
Jeremy Haile
On Wed, 24 Jan 2007 14:19:05 -0500, Jeremy Haile [EMAIL PROTECTED]
said:
pgstat.stat was last updated 1/22 12:25pm - there is no pgstat.tmp.
Coincidentally (I think
if there is anything else I can do to help debug this
problem.
Do you know of any workaround other than restarting the whole server?
Can the collector be restarted individually?
Thanks,
Jeremy Haile
On Thu, 25 Jan 2007 12:42:11 -0500, Tom Lane [EMAIL PROTECTED] said:
Jeremy Haile [EMAIL
process, it does gets restarted, although
sometimes it takes a minute.
Since it only seems to update pgstat.stat once after restarting, I'd
need to kill it once-a-minute to keep my statistics up to date =) So,
unfortunately it's not a great workaround to my problem.
Jeremy Haile
PROTECTED] said:
Jeremy Haile [EMAIL PROTECTED] writes:
Unfortunately I don't have any debugging tools installed that would work
against postgres - although I'd be glad to do something if you could
tell me the steps involved. I can reproduce the issue quite easily on
two different Windows machines
AFAIR (Magnus can surely confirm) there were some other tables that
weren't showing stats as all zeros -- but there's no way to know whether
those numbers were put there before the collector had frozen (if
that's really what's happening).
Yeah - I have numbers that updated before the stats
Apparantly there is a bug lurking somewhere in pgwin32_select(). Because
if I put a #undef select right before the select in pgstat.c, the
regression tests pass.
May be, problem is related to fixed bug in pgwin32_waitforsinglesocket() ?
WaitForMultipleObjectsEx might sleep
We have had lots of reports of issues with the stats collector on
Windows. Some were definitly fixed by the patch by OT, but I don't
think all.
Here were a couple of other reports I found:
http://archives.postgresql.org/pgsql-hackers/2006-09/msg00415.php
it into
another DB - but as Tomi said, when you have to do primary key
generation, row merging, data cleanup, and data transformations - I
would use some sort of ETL tool over just SQL.
My 2 cents,
Jeremy Haile
On Fri, 26 Jan 2007 15:14:22 +, Tomi N/A [EMAIL PROTECTED] said:
Besides being easy
This utility is useful for creating junctions in Windows:
http://www.microsoft.com/technet/sysinternals/FileAndDisk/Junction.mspx
I am using this to symlink my pg_xlog directory to another disk and it
works great.
Jeremy Haile
On Fri, 26 Jan 2007 18:27:04 +, Roman Neuhauser
[EMAIL
provide me with a patched exe for Win32? If not, I could try
to get my system setup to build for Windows, but I'm not sure what all
that would involve.
Thanks,
Jeremy Haile
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Using standard build (none of the things you mentioned) on 8.2.1
currently.
I really appreciate it!
On Fri, 26 Jan 2007 21:24:09 +0100, Magnus Hagander
[EMAIL PROTECTED] said:
Jeremy Haile wrote:
Applied to HEAD and 8.2 --- assuming the Windows buildfarm machines go
green, we should
Will do - thanks Magnus! I'll test it for a while and post the results
here.
Jeremy Haile
On Sat, 27 Jan 2007 17:21:23 +0100, Magnus Hagander
[EMAIL PROTECTED] said:
Jeremy Haile wrote:
Using standard build (none of the things you mentioned) on 8.2.1
currently.
I really appreciate
to assist.
Jeremy Haile
On Sat, 27 Jan 2007 11:23:39 -0500, Jeremy Haile [EMAIL PROTECTED]
said:
Will do - thanks Magnus! I'll test it for a while and post the results
here.
Jeremy Haile
On Sat, 27 Jan 2007 17:21:23 +0100, Magnus Hagander
[EMAIL PROTECTED] said:
Jeremy Haile wrote
, everything in this thread is theoretical.
Cheers,
Jeremy Haile
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
30 matches
Mail list logo
