On Tue, Jan 3, 2012 at 5:47 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Tue, Jan 3, 2012 at 4:40 AM, Noah Misch <noah@leadboat.com> wrote:
>> On Tue, Jan 03, 2012 at 01:18:41AM +0000, Simon Riggs wrote:
>>> Just for the record, yes we do run multiple catalog scans in some
>>> parts of the code.
>>>
>>> So I can see how we might trigger 4 nested scans, using cache
>>> replacement while scanning, so best assume more, with no guarantee of
>>> them being neatly stacked for pop/push type access.
>>
>> Yeah, I wouldn't want to commit to a nesting limit.
>
> Agreed
>
>> However, I _would_ have
>> expected that a stack would suffice; PushActiveSnapshot()/PopActiveSnapshot()
>> is adequate for a great deal of the backend, after all. In what sort of
>> situation do catalog scans not strictly nest?
>
> It's possible. Making assumptions about what is possible bit me
> before, as you showed.
>
> I've seen code where we are explicitly running two concurrent scans.
>
> I don't want to put unnecessary and subtle assumptions into catalog
> scan code so I'm working on the assumption that endscan may not be
> called in strict FIFO order. The difference is fairly minor and
> doesn't restrict us in other ways.
I feel like the first thing we should be doing here is some
benchmarking. If we change just the scans in dependency.c and then
try the test case Tom suggested (dropping a schema containing a large
number of functions), we can compare the patched code with master and
get an idea of whether the performance is acceptable. If it is,
changing everything else is a mostly mechanical process that we can
simply grind through. If it's not, I'd rather learn that before we
start grinding.
I started to do this before Christmas, but then I ... went on
vacation. Here's Perl script that can be used to generate an SQL
script to create as many functions as you'd like to try dropping at
once, in case it's helpful. The idea is to run the resulting SQL
script through psql and then test the speed of "DROP SCHEMA
lots_of_functions CASCADE;".
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
