inds that there really is some real-world
performance issue. AFAIK, everything in this thread is theoretical.
Cheers,
Jeremy Haile
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
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 Haga
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
&g
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 buildfar
e
who could 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
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 Neu
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:
>
> We have had lots of reports of issues with the stats collector on
> Windows. Some were definitly fixed by the patch by O&T, 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
http://archives.postgresql.org/pgsql
> > > >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() ?
> > > WaitForMultipleObject
> 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 sta
-0500, "Tom Lane" <[EMAIL 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
> >
postgres.exe -forkcol" 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 work
me know 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]
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.
>
were 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
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
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. Also,
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
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?
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:
> "E
> 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 recentl
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 currently
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?
SEL
> 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.
> cop
> 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)---
umstances that made one option 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:
&g
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 s
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?
>
>
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 tha
p is setup). 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 y
30 matches
Mail list logo
